DDD系列：五、实际项目应用

引言

DDD的设计目标是什么？解决了什么问题？

   Domain-Driven Design 是一种软件/应用结构设计方法论，它把 领域模型的重要性提高到了数据模型之上，用于应对复杂且多变的业务，解决架构和代码落地问题。DDD中推出了很多的规范和建议，但使用 DDD 是为了帮我们解决问题，而不是在简单问题上强制某种规范来限制我们。

   DDD的设计目标是，将软件设计与业务领域模型相结合，同时 分离技术和业务耦合的复杂性，提高软件的设计质量。同时，优先设计业务领域模型，屏蔽掉了大部分数据模型、技术实现细节，让开发者和上游下游的业务沟通上，减少gap。

   在传统的MVC分层架构下，我们将项目结构分为Controller，Service，DAO 三层，所有的业务逻辑都在 Service 中体现，而我们的实体类 Entity 却只是充当一个与数据库做ORM映射的数据容器而已，它并没有反映出模型的业务价值，所以又把这种模型称为“贫血模型”。
   “贫血模型”有什么坏处呢？在我们的代码 中将会到处看到各种的setter方法和各种各样的参数校验的代码，尤其是在Service层，但是这些代码它并没有反映出它的业务价值。这种模式下认为 数据模型优先，
   所以会导致开发人员和产品经理在讨论问题的时候，完全是从两个角度在思考问题。开发人员听到需求后，脑袋里想的并不是如何反应出业务的价值，而是考虑的是数据库表怎么设计，字段该怎么加这些问题。所以DDD中提出了通用语言这么一个概念，并且基本将通用语言的概念贯穿于整个落地的过程。这样会大大的减少成员之间的沟通成本（前提是大家都从心里接受了DDD）。

   DDD的架构中，为了避免设计出的领域模型在迭代的过程中腐败掉了，开发前期需要非常熟悉业务才能抽象出合适的领域模型，因此需要投入很多的时间和精力。针对这个问题，我们在DDD项目的实践中做了部分的调整，允许 Application 层承载部分不重要的业务，详细的内容见下文。

1 项目结构

1.1 module依赖关系

说明：

• Test模块：完成单元测试或启动应用的集成测试
• bootStrap模块：应用启动信息模块
• service-impl：应用服务流程编排模块，和facade实现模块，合并原因详见 2.2
• domain（model）：核心领域模型的定义和domain领域服务能力定义模块
• domain-impl：领域服务能力逻辑实现模块
• infrastructure：应用内集成的外部接口模块
• facade：对外提供的facade包
• utils：基础工具包

思考：

1. 为什么要把domian（model）层和其实现 domain-impl 放在不同的层级去实现？
   • 有助于保持 domain 层的纯净，方便进行单元测试和维护，也是为了更好地分离关注点
2. 为什么领域服务层的model模块，要依赖基础设施层facade模块？
   • 可以在model中，使用到facade定义的 ValueObject

1.2 module结构

介于数据安全问题，后续内容不公开发布，有兴趣可联系作者