| name | DDD 分层架构 (COLA) |
| description | 以领域层为核心的应用分层架构，分为接口门面层、应用层、领域层、仓储层、基础设施层，保证高内聚低耦合和业务逻辑稳定。 |
DDD 只给出了分层思想（领域层要稳定、技术细节要隔离），并未规定具体模块划分。阿里巴巴 COLA 架构在经典 DDD 分层基础上结合工程实践，给出了面向团队协作的可落地模块划分。本文档融合了 COLA 的思想和互联网团队的实际经验。
核心原则：
┌─────────────────────┐
│ testsuite 测试套件 │ ── 依赖所有模块
└─────────────────────┘
│
┌─────────────────────┐
│ main 主程序入口 │ ── 启动入口、配置聚合
└──────────┬──────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌──────────┐ ┌──────────────────┐
│ controller 控制层 │ │ facade-impl │ │ repository │
│ (HTTP 入口) │ │ (RPC/SOA) │ │ infrastructure │
└────────┬────────┘ └─────┬────┘ └────────┬─────────┘
│ │ │
└────────┬───────┘ │
▼ │
┌─────────────────┐ │
│ application 应用层 │──── 虚线依赖 ─┤
└────────┬────────┘ │
▼ │
┌─────────────────┐ │
│ domain 领域层 │◀──────倒置依赖─┘
└────────┬────────┘
▼
┌─────────────────┐
│ utility 工具层 │
└─────────────────┘
┌─────────────────┐
│ facade 接口包 │ ── 对外 API 声明，供其他应用依赖
└─────────────────┘
Application.java）@Controller）应用层编排领域层的原子方法完成业务用例，但不含业务规则。
允许的职责：
@Transactional）禁止的事情：
@Service
public class SubscribeAppService {
@Autowired private SubscriptionDomainService subscriptionDomainService;
@Autowired private PaymentDomainService paymentDomainService;
@Autowired private DomainEventPublisher eventPublisher;
@Transactional
public SubscriptionInfo subscribe(SubscribeCommand cmd) {
Payment payment = paymentDomainService.pay(cmd.getPaymentReq());
Subscription subscription = subscriptionDomainService.subscribe(payment);
eventPublisher.publish(new SubscriptionCreatedEvent(subscription));
return Model2InfoConverter.toInfo(subscription);
}
}
领域层是应用的心脏，一个聚合一个 package。
包含内容：
domain/
├── subscription/ ← 一个聚合一个包
│ ├── Subscription.java (聚合根 / 实体)
│ ├── SubscriptionId.java (值对象)
│ ├── SubscriptionStatus.java (枚举)
│ ├── SubscriptionDomainService.java
│ ├── SubscriptionRepository.java (仓储接口)
│ ├── SubscriptionFactory.java (工厂)
│ └── events/
│ └── SubscriptionCreatedEvent.java
└── shared/
└── ... (共享值对象、基础类型)
关键约束：
@Repository
public class SubscriptionRepositoryImpl implements SubscriptionRepository {
@Autowired private SubscriptionMapper subscriptionMapper;
@Override
public Subscription findById(SubscriptionId id) {
SubscriptionDO data = subscriptionMapper.queryById(id.getValue());
return DO2ModelConverter.toModel(data);
}
@Override
public void save(Subscription subscription) {
SubscriptionDO data = Model2DOConverter.toDO(subscription);
if (data.getId() == null) {
subscriptionMapper.insert(data);
} else {
subscriptionMapper.update(data);
}
}
}
| 后缀 | 含义 | 所在层 |
|---|---|---|
| DO | Data Object，数据库模型，字段和表一一对应 | repository |
| Model | 领域模型，逻辑核心 | domain |
| DTO | 外部传输对象，对外交互用 | facade |
| Info | 内部传输对象，application ↔ domain | application / domain |
| VO | Value Object，值对象或 facade 接收的 DTO | facade / domain |
| Query | 仓储查询参数封装 | domain（定义）/ repository（使用） |
| Request | Facade 接口的请求参数封装 | facade |
| Converter | 类型转换器，建议逐字段手写（避免 BeanUtils 带来的字段变更盲点） | 各层 |
| 后缀 | 角色 | 所在层 |
|---|---|---|
| Controller | HTTP 控制器 | controller |
| Facade / FacadeImpl | RPC 门面服务（可细分 WriteFacade / ReadFacade） | facade / facade-impl |
| AppService | 应用层服务（可细分 WriteAppService / ReadAppService） | application |
| DomainService | 领域服务 | domain |
| Repository / RepositoryImpl | 仓储接口 / 实现 | domain / repository |
| Mapper | MyBatis 查询接口 | repository |
| Client / ClientImpl | 中间件服务依赖接口 / 实现（防腐） | domain / infrastructure |
| FacadeClient / FacadeClientImpl | 外部 RPC 服务依赖接口 / 实现（防腐） | domain / infrastructure |
| Configuration | 各层自己的 Spring 配置 | 各层 |
Service / Repository / Client / DAO 方法前缀：
query → 查询单个对象
list → 查询多个，复数结尾：listOrders
page → 分页查询，复数结尾：pageOrders
count → 统计
insert → 插入
delete → 删除
update → 修改
| 经典 DDD 层 | 本架构对应模块 |
|---|---|
| 用户界面层 (UI) | controller + facade + facade-impl |
| 应用层 (Application) | application |
| 领域层 (Domain) | domain |
| 基础设施层 (Infrastructure) | repository + infrastructure + utility |
这套分层看起来繁琐（一个请求要经过 Controller → Facade → FacadeImpl → AppService → DomainService → Repository → Mapper），但它是面向团队协作设计的：
何时该上 DDD 分层：
✓ 核心域，业务规则复杂，长期演进
✓ 5 人以上团队协作
✓ 微服务拆分需要清晰边界
✗ 工具类、通用域，简单 CRUD
✗ MVP / POC 快速验证阶段
| 概念 | 关系 |
|---|---|
| 领域模型 | 领域层承载完整的领域模型 |
| 聚合 | 领域层一个聚合一个包 |
| 仓储 | 接口在 domain，实现在 repository（倒置依赖） |
| 应用服务 | 对应 application 模块 |
| 领域服务 | 放在 domain 模块的聚合包下 |
| 六边形架构 / 清洁架构 | 都体现"依赖指向领域层"原则，本分层是它们的工程落地 |
核心：围绕领域层分层，外层依赖内层，技术细节通过倒置依赖与领域层解耦。
实践：六层 + 命名规范 + 方法前缀约定，保证团队代码质量下限。
记住：这套架构为团队协作而生，不是为单人项目设计。用规范的代价换来的是可维护性和业务可演进性。
以聚合根为边界，包含多个相关Entity和ValueObject的集合。保证数据一致性和事务边界。
在DDD中具有唯一身份标识和生命周期的对象，通过身份而非属性值相等判断。
封装复杂对象和聚合的创建过程，将创建职责从领域对象中剥离，保证聚合创建时的不变量满足。
没有身份标识，通过属性值判断相等的对象。不可变，通常代表领域中的度量或描述。
命令查询责任分离，将数据的写入操作和读取操作分别用不同的模型处理，优化各自的性能。
将DDD战略设计应用于微服务架构，限界上下文指导服务拆分，领域事件实现服务间通信。