DDD专栏12、专栏总结 走出自己的DDD

​ 本专栏到这里，也就进入了尾声。实际上，DDD从2004年就被提出，多年来经过很多大神的研究与分享，DDD已经从高高在上的理论空间慢慢沉淀到了我们身边。业界对于DDD的难点，也从学习理解，下沉到了落地实践。就像专栏开篇所说的，这个专栏并不是DDD的布道文，而只是作为一个载体与大家分享我对于DDD的理解。最后这一讲，就基于我自己的理解谈谈DDD落地时需要注意的几个地方。

要认识到DDD的不足

​ DDD基于多方面的考虑，设计出非常多的设计原则。这些条条框框多了，很多人在实践时，就总是在担心或者犹豫这是不是原汁原味的DDD。受限太多，反而缚手缚脚，很容易导致过度的设计，反而增加了开发的复杂度和项目成本。其实从本专栏的分析中也能看到， DDD也是鼓励系统设计由模糊逐渐转为成熟的。DDD本身也并不是银弹，落地到具体项目后，DDD的理论体系要映射到具体的业务场景，也同样需要有一个由模糊慢慢成熟起来的过程。

• DDD缺乏一个规范的过程指导。虽然他提出了通用语言、事件风暴等指导方式，但是具体要如何操作？执行后的效果如何？依然取决于整个团队的设计经验以及执行能力。所以，以人为本才是DDD的正确打开方式。
• DDD没有万能的需求管理体系。DDD虽然讲到了很多模式，有战略设计、战术设计，但整体来说，怎么从需求分析进入限界上下文分析，怎么去识别限界上下文，到后面怎么去建模，还是没有一个完整规范的过程指导的。
• DDD虽然以模型驱动设计为主线，但是却并没有给出明确的领域建模方法。虽然事件风暴有助于软件团队对领域范围打成大致的共识。但是在对领域进行具体建模时，依然需要设计人员采用名词动词法、类型流等传统设计方式来进行综合设计。