DDD领域驱动设计实战-分层架构及代码目录结构

• 应用层也是微服务间的交互通道，它可调用其它微服务，完成微服务间的服务组合和编排。

开发设计时，不要将本该放在领域层的业务逻辑放到应用层。庞大的应用层会使领域模型失焦，时间一长，微服务就会退化为MVC。

应用服务是在应用层，负责

• 服务的组合、编排、转发、转换和传递，处理业务用例的执行顺序以及结果的拼装，以粗粒度服务通过API网关发布到前端

• 发送或订阅领域事件

[](

)应用层代码目录结构

存放应用层服务组合和编排相关的代码。

应用服务向下基于

• 微服务内的领域服务，或

• 外部微服务的应用服务

完成服务的编排和组合

向上为用户接口层提供各种应用数据展现支持服务。

应用服务和事件等代码会放在这层目录。

[](

)Event（事件）

主要存放事件相关代码。包括两子目录：

[](

)publish

主要存放事件发布相关代码。比如发布用户创建事件给其它微服务。

[](

)subscribe

主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。

虽然应用层和领域层都可进行事件的发布和处理，但为实现事件的统一管理，推荐将微服务内所有事件的发布和订阅处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。

[](

)Service（应用服务）

应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。

可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。

比如内部服务->创建用户；外部服务->创建日志。

2.3 领域层

---

主要包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

实现核心业务逻辑，通过各种校验保证业务正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域模型的业务逻辑主要由实体和领域服务实现：

• 实体采用充血模型 实现所有与之相关的业务功能。

实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体或值对象无法实现，就会用到领域服务，它可组合聚合内的多个实体或值对象，实现复杂业务逻辑。

3 Domain（领域层）

============================================================================

存放领域层核心业务逻辑相关的代码。

可包含多个聚合代码包，共同实现领域模型的核心业务逻辑。聚合以聚合内的实体、方法、领域服务和事件等代码会放在该层目录。

领域层包括一个或多个聚合的实体类、事件实体类、领域服务以及工厂、仓储相关代码。一个聚合对应一个聚合代码目录，聚合之间在代码上完全隔离，聚合之间通过应用层协调。

Domain 由一或多个聚合包构成，共同实现领域模型的核心业务逻辑。

聚合内的代码模型是标准和统一的，包括：entity、event、repository、service 子目录

Aggregate（聚合）

---------------------------------------------------------- <