DDD不是银弹，只是微服务最佳实践的一种代码结构风格
从DDD角度来看MVC
从代码角度来说
- 实体模型：MVC使用的是贫血模型，业务逻辑全在service层。而DDD使用的是充血模型，与仓储无关的业务逻辑放在领域模型中，与仓储有关的业务逻辑放在领域层
- 编程：MVC面向数据模型编程；DDD面向领域编程（领域模型与领域中的所有业务都有关系）
- 实体关系：MVC实体之间关系复杂，有可能导致牵一发而动全身，而且对外接口会暴露实体；DDD领域模型高度内聚，极低的耦合，就算一个领域需要使用另外一个领域模型的业务逻辑或者数据，也是在领域层做一层防腐，所以不存在暴露领域模型的风险。
- 聚耦合程度：MVC业务层逻辑过多，甚至在业务层出现原子操作和非原子操作；DDD分为四层，展示层用于处理接口格式和数据异常等问题、应用层负责编排领域层逻辑、领域层是业务逻辑，方法基本都是业务逻辑的最小单元、基础设施层负责领域模型与仓储的交互。
从项目管理角度来说
- MVC理解成本高，新人熟悉困难；DDD业务更细，结构清晰， 理解容易
- MVC代码改动影响范围大；DDD业务更细，代码改动影响不大
领域驱动设计DDD
分层架构
架构映射
存在的问题
刚刚一直在说DDD多好，MVC多差，但是DDD也存在很多问题：
- 学习成本大
- 编码复杂
学习成本大
DDD中的概念和玩法很多，而且国内公司比如人保、点触等对于DDD的一些细节规范不一样，所以导致开发人员入门DDD除了需要啃几本书来理解DDD核心理念，还要去深入学习公司的DDD规范。
- 实现领域驱动设计
- 领域驱动设计精粹
编码复杂
DDD由于概念多，开发会比较复杂。举个例子，po、领域模型，防腐值对象和实体，这三个概念其实是一个数据，po是仓储层数据，领域模型是领域层数据，防腐层值对象和实体是其他领域模型的数据。而且对于这些数据结构，需要写对应的转换函数，不可以直接使用。
应用场景
- 中大型项目
- 微服务
为什么小型项目不适合DDD呢？因为DDD里面的限制还是挺多的，而且开发比较复杂，比如当前BC需要调用其他BC业务时，需要在自己的领域层做一层防腐。所以小型项目使用DDD会很大程度会降低开发效率
总结
DDD是一种很好的代码结构风格，在设计初期可以很容易将需求转成领域模型，定义好领域边界，建立领域内部的通用语言；也能够帮助业务人员和开发人员梳理清楚复杂的业务规则。
此外，DDD也不是银弹，只是一种代码结构风格，对于开发者来说，很够找到适合自己业务与技术习惯的代码结构风格才是最好的代码结构风格。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
