【DDD】学习笔记-领域驱动设计的代码模型

理解了限界上下文和分层架构的本质，要确认系统的代码模型自然也就水到渠成。没有必要要求每个团队都遵守一套代码模型，但在同一个项目中，代码模型应作为架构规范要求每个团队成员必须遵守。当然，在遵守规范的同时，每个人需要理解如此划分代码模型的意义所在、价值所在。

遵循领域驱动设计思想的代码模型

结合领域驱动分层架构设计思想，通过引入整洁架构与六边形架构以及上下文映射等设计原则与模式，我们对层、层之间协作、跨限界上下文之间的协作已经有了深入的理解。当我们考虑限界上下文的代码模型时，需要考虑纵向架构除前端之外的所有层次或模块。故而在代码模型设计因素中，需要考虑层与模块之间的职责分离与松散耦合，同时还必须将整个限界上下文作为基本设计单元，照顾到限界上下文之间的协作关系。基于这样的设计因素，结合自己的项目经验，给出了如下代码模型推荐：

- application
- interfaces
- domain
- repositories
- gateways
    - controllers
    - persistence
    - mq
    - client
    - ...

以下是对代码结构的说明。

• application：对应了领域驱动设计的应用层，主要内容为该限界上下文中所有的应用服务。
• interfaces：对 gateways 中除 persistence 之外的抽象，包括访问除数据库之外其他外部资源的抽象接口，以及访问第三方服务或其他限界上下文服务的抽象接口。从分层架构的角度讲，interfaces 应该属于应用层，但在实践时，往往会遭遇领域层需要访问这些抽象接口的情形，单独分离 出 interfacesÿ