近年来，DDD（领域驱动设计）备受关注，关于其是银弹还是垃圾的分析在网络上层出不穷。
在组内，一名同学对DDD着迷，原因是他花钱学习了DDD的课程，并希望在工作项目中实践，让理论落地。
DDD的分层架构
对于了解DDD的开发者来说，支持DDD的观点主要认为它是一种有效的软件开发方法，有助于设计高质量的软件模型。当正确实现时，DDD完成的设计恰恰就是软件的工作方式。
业务系统设计的关键在于如何定义系统的模型以及模型之间的关系，特别是领域模型的定义。当模型确定后，模型之间的关系也随之明确。
Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式，包括接口层、领域层、基础设施层。
接口层主要负责与外部系统进行交互&通信，如dubbo服务、Restful API等；领域层是领域模型系统的核心，负责维护面向对象的领域模型，业务逻辑在此层实现；基础设施层为前三层提供支撑，避免领域层掺杂具体实现，从而“污染”领域模型。
贫血模型与模型
贫血模型中，实体类仅作为数据容器，不体现模型的业务价值。在代码中将看到大量的setter方法和参数校验代码，尤其在Service层。DDD推荐采用模式编写代码，按OOP方式抽象行为，把行为挂在对象上，而非以过程式方式编写代码。模式使对象具有关联行为，而不仅仅是数据库表的字段映射。DDD声称的模式优势在于行为装到对象内部，便于阅读流程代码。但实际上，即使不使用OOP行为，也可以将业务step做好封装和复用。服务粒度较小的项目中，模式的优势可能并不明显。
关于指导微服务划分
很多人认为DDD可以有效地指导微服务拆分，主要通过界限上下文来实现。限界上下文是DDD中用于划分不同业务边界的元素，可以解决不同业务问题。数据与功能的抽象是划分限界上下文的主要方式。使用DDD指导微服务划分能在一定程度上弥补经验的不足，做出有理有据的系统架构设计。
领域驱动开发的关注点在于领域模型，所有的考虑都应从领域的角度出发。领域模型必须能够精准地表达业务逻辑，并在开发过程中不断完善，指导工程师的开发工作。国内关于DDD的最佳实践较少，承担的项目失败的风险较大。DDD现了许多新概念和术语，如聚合根、值对象等，需要开发人员具备较高的能力。DDD需要在领域建模上花费很多时间和精力，可能导致付出和收益不成正比。尽信书不如无书，实践是检验真理的唯一标准。在实际应用中，需要根据具体情况权衡DDD的ROI，并在实践中不断探索和调整。
