DDK 三层架构

适配层、业务层、基础设施层。业务层是四层架构中应用层与领域层的合并，适用于业务规则简单、不值得付出四层抽象成本的服务。用 ddk-layer3-archetype 生成。

各层职责

层	职责
adapter	协议适配：校验 *Request、转成命令、包装 ApiResponse，不写业务判断
business	用例编排、事务与业务规则；实体仍可继承 ddk-core 的领域模型基类；声明仓储与外部能力接口
infrastructure	实现业务层接口：仓储、实体 ↔ PO 转换、Mapper、外部调用

生成项目

mvn archetype:generate \
  -DarchetypeGroupId=com.ddk -DarchetypeArtifactId=ddk-layer3-archetype -DarchetypeVersion=1.0.0-SNAPSHOT \
  -DgroupId=com.acme -DartifactId=notice-service -Dpackage=com.acme.notice -DinteractiveMode=false

包结构

com.acme.notice
├── Application
├── adapter
│   └── controller           REST 控制器与 *Request
├── business
│   ├── command / query      用例入参
│   ├── response             对外响应 *Response.from(...)
│   ├── service              业务服务：编排、事务
│   ├── model                实体、值对象、枚举
│   ├── event / handler      业务事件与订阅方
│   ├── acl                  仓储契约 *Repository、外部能力接口 *Gateway
│   └── error                业务错误码
└── infrastructure
    ├── acl/impl             接口实现
    ├── converter            实体 ↔ PO 转换器
    └── orm/po, orm/mapper   持久化对象与 Mapper

收益与代价

收益：

• 层间转换更少：少一次对象转换和一层接口
• 上手更快：结构扁平，不需要先理解聚合边界才能写第一个接口
• 避免过度设计：业务规则本来就简单时，四层的抽象是净负担

代价：

• 规则和编排混住：用例编排与业务规则在同一个 Service 里，分支增多后会迅速变长
• 没有天然的聚合边界：不变量容易散落到 Service 里，退回贫血模型。状态变更与校验仍应优先写在实体方法里
• 拆回四层有成本：发现需要拆的时候，调用方已经依赖了合并后的接口

判断标准：当你开始需要为「什么时候允许改这个字段」写注释时，就该换回四层。

依赖倒置

业务层声明接口，基础设施层实现；业务层与适配层都不直接引用基础设施层的类。生成的项目自带 ArchitectureTest，通过 ArchGuard.check 执行 THREE_LAYER_ARCHITECTURE_RULE 与 DDK_INTERNALS_MUST_NOT_BE_USED，违规明细与修复建议写入 target/archguard/。

三层规则不要求业务层框架无关：它合并了应用层，应用服务本来就带 @Service、@Transactional。详见架构守卫。