DDD你真的理解清楚了吗（2）

充血模型 vs 贫血模型

随着软件系统的复杂化，开发团队越来越倾向于实践DDD（领域驱动设计）来解决设计开发和更新维护的问题。DDD有助于理清复杂业务，但学习成本高，难以落实。

模型选择的困境

实践DDD时，团队在领域建模后，面临选择贫血模型或充血模型的难题，两者争议多年仍无定论。

贫血模型和充血模型

Eric Evans的著作《领域驱动设计》后，Martin Fowler批评了贫血模型。贫血模型的设计中领域对象仅包含属性和get/set方法，所有操作都在Service层实现，导致业务与技术实现耦合。

充血模型则尝试将领域模型的原貌还原为领域对象，包含所有业务操作，但实现中面临诸多挑战。

结合两种模型

作者认为，纯粹采用贫血模型或充血模型均有问题，应结合二者，取长补短。

落地领域模型

领域模型编码时，应将对象关系落地为领域对象设计，如订单对象应包含用户、地址、订单明细等引用。将一些业务操作和封装写入领域对象中，但不包括需要远程调用的操作。

实际操作过程

前端提交订单后，后台通过Controller转换json为订单对象，然后Controller调用Service中的方法。Service中部分操作采用贫血模型，特别是涉及远程调用的操作，其余通过领域对象实现充血模型。

模块间的交互

Service与Service间交互，领域对象内部封装，业务代码与技术实现分离，适应技术变迁。

数据持久化

DAO层负责数据持久化，根据对象关系定义保存数据库。查询订单需同时查询多个表，并装配成完整订单对象，领域模型中的关系通过DSL配置表达。

(待续)