DDD 是银弹吗？

上面介绍了一下D瓜哥的个人经历，是付出了一点的时间和精力的，由此引出了第一个问题：如何快速上手？对于一个工作多年，经验丰富，也算勤奋好学的高级码农，上手还如此困难重重，那么对于一个刚刚参加工作的职场新人，上手是否会更加困难？又该如何克服这个困难？

任何一家公司，尤其是大型技术公司，都是由初中高级工程师组成的，而且成员人数也是由多到少，参与实际开发工作，大概率也会由多到少，初级开发工程师干了大量的实际编码工作。如果无法吸引大多数的初级工程师参与进来，只有个别的高级工程师去落地，那么，所谓的领域驱动设计，只能成为空中楼阁，海市蜃楼。华而不实，无法落地。

但是，由于经验少，这对于初级工程师来说，也许是一个优势。毕竟，一张白纸，可以画出各种美丽的画卷。中高级工程师已经习惯于传统的开发模式，思维已经定格。但是，初级工程师，反倒是嗷嗷待哺，更容易塑性。可惜的是，现在没有好的示例可以学习。

快速上手的最好办法，就是给一个完整的示例，拿来直接抄作业。对于入门的程序员，学东西上手最快的办法就是抄代码。把示例代码，拿过来改吧改吧就能跑起来，无形中就学会怎么写代码了。对于传统的三层架构，有太多的示例可以来学习了，比如 SpringSide。

从 《Domain-Driven Design》 这本书在 2003 年出版到现在，已经有 21 年了。到现在为止，也没有见到一个开源的、能运行起来的基于领域驱动设计的项目。也可能是鄙人孤陋寡闻，坐井观天，没有发现。如果谁发现了，欢迎向我反馈。

作为对比，我们来看一下 Spring 的发展过程。Spring 的思想最早是在 《J2EE Development without EJB》 这本书里出现的，这本书是在 2004 年 6 月出版的。这本书出版后，开源社区根据这本书里面的思想及代码片段，开发出了 Spring 框架。在两年后，Spring 之父 Rod Johnson 接着出版了 《Professional Java Development with the Spring Framework》，系统介绍了一下 Spring 框架的各种使用案例。到 2008 年我上大学的时候，在国内的培训行业，已经开始重点讲解 Spring 了。

期待一个完整的、基于领域驱动设计的、能正常运行起来的开源项目尽早出现！

如果大家经常在网上看领域驱动相关的资料，也许会发现，大家对领域驱动的解读，有各种各样的。举一个最简单的例子：基于领域驱动设计的架构是什么样子的？大家去搜一下，会有各种各样的架构，比如六边形架构，比如洋葱架构。

总之，就是没有一个统一的标准，这样就很容易陷入扯皮。当然，一些高层的设计，比如架构，可以统一规定用什么架构。但是，业务逻辑的编码实现，这些底层的细节，现在没有一个统一的标准。业务逻辑放在哪里有太多可以商榷的地方，有商榷就有分歧，每个人都可以说出自己选择的理由，最后的结果就是乱套。举个例子🌰，在做项目中，遇到一个排序问题，原来的实现里，已经有一个地方做排序，后来要增加新业务，需要增加一个排序，开会讨论，多数人觉得应该放一起，但编码的小伙伴觉得应该放在另外一个地方。最后，谁写代码谁做主。这样的分歧会很多，如果一个项目只有一个人维护，也许标准会始终比较统一，但维护的人多之后，大家有不同的认知，最后的结果是业务逻辑会散落在各个地方。

领域驱动设计，有太多值得商榷的地方，这些地方都需要花时间慢慢思考琢磨的。但是，通常情况下，大家有 KPI 需要背负，有 Deadline 的压力，在这种情况下，能完成 KPI 就不会扣绩效；代码写的再漂亮，KPI 没有完成，差绩效就要我来背。那么，大家本能地就会放弃思考，先完成 KPI 再说，肯定是怎么快速完成任务，怎么来。最后，代码就会越来越来乱。所谓的“复杂性应对之道”，就会成为一句空话。

上面三个问题就是我实践的一个结果，更准确说是三个疑问点。没有答案，有答案的小伙伴，欢迎提供答案。

回到文章标题：DDD 是银弹吗？坦白讲，D瓜哥不知道。私以为，在解决好上述三个问题，尤其是提供统一的标准之前，DDD 绝对不是银弹，甚至是焦油坑。

但是，也不要对 DDD 一棒子打死！私以为，DDD 里面统一语言，领域划分，限界上下文等还是非常具有指导意义的。把各自领域划分好，定义好各自交互接口，至于内部实现，就“凯撒的归凯撒；上帝的归上帝。”

最后，借用前腾讯首席技术官张志东一句话做个总结：优雅的接口，龌龊的实现。