怎么感觉在国内没什么人用啊

由于公司领导的要求，所有的软件开发都要将DDD作为指导思想，并且要接受敏捷的思想；"迫不得已"下拜读了《实现领域驱动设计》这本书，将会在公司的内部系统上全面实践DDD。

DDD把领域模型的重要性提高到了数据模型之上，在传统的MVC分层架构下。我们将项目结构分为Controller，Service，DAO 这三个主要的层，所有的业务逻辑都在Service中体现，而我们的实体类Entity却只是充当一个与数据库做ORM映射的数据容器而已，它并没有反映出模型的业务价值。所以又把这种模型称为“贫血模型”。“贫血模型”有什么坏处呢？
在我们的代码中将会到处看到各种的setter方法和各种各样的参数校验的代码，尤其是在Service层，但是这些代码它并没有反映出它的业务价值。这就是事务脚本的架构下，所呈现出来的弊端，这种模式下认为数据模型优先，所以会导致开发人员和产品经理在讨论问题的时候，完全是从两个角度在思考问题。开发人员听到需求后，脑袋里想的并不是如何反应出业务的价值，而是考虑的是数据库表怎么设计，字段该怎么加这些问题。

所以DDD中提出了通用语言这么一个概念，并且基本将通用语言的概念贯穿于整个落地的过程。这样会大大的减少成员之间的沟通成本（前提是大家都从心里接受了DDD）。

为什么DDD难以落地呢？

第一，国内关于DDD的最佳实践还是太少了，除了知名的几个大厂以外很少看到有关于DDD的落地实践。这里附上美团的DDD实践，美团领域驱动设计；最佳实践太少意味着，我们可以参考的资料就少，承担的项目失败的风险就大。

第二，DDD中出现了很多的概念和术语，比如 聚合根，值对象，六边形架构，CQRS(命令和查询职责分离)，事件驱动等等概念。很多人看到了这么多概念的时候，心中就开始打退堂鼓了。

第三，DDD需要我们在领域建模花费很多的时间和精力，而且还可能导致付出和收益不成正比的情况。因为在界限上下文的划分上是非常考验架构师的业务水平。如果没有将业务模型很好的识别出来，那么可能很快模型就会在迭代的过程中腐败掉了。

评论

  1. 只依赖其中的某些思想或者部分框架 感觉还行
  2. 其实团队也很重要
  3. 团队水平要求高。要应用DDD必须持续迭代重构完善领域模型，否则模型会腐化，越来越难用，最终又回到之前的开发模式。就这2点就拦下了绝大多数项目的实施。 不过其中的思想，还是很值得开发借鉴和思考的，值得学习。