关于DDD（领域驱动设计），有很多种说法，对于初学者，多少会有一些神秘感，甚至无从下手。最难的是，读完了DDD相关的几本书，仍然不知道如何落地DDD。如何使用DDD进行建模？如何将DDD领域模型实现出来？好像都是比较难的事情。
确实，DDD落地比较困难，我本人也是接触了DDD的项目，也读过了DDD的一些书籍，对于DDD的落地 ，仍然不敢说胸有成竹。但是在不断跟别人谈论DDD的过程中，我渐渐发现，DDD难以落地有两个比较大的障碍
障碍一：缺乏基本的软件建模能力，且不说DDD建模能力。
看到太多想学习软件建模技术，但连一个UML图都画不好的程序员。在这种情况下，无论如何是无法入门DDD的。那是因为在“建模”的概念上，还无法跟作者对齐，接下来的对话就无从谈起了。所以当我们还不具备基本的建模思想时，先不要着急去学习DDD，先去补充一下基本的建模能力（可以从面向对象开始）。如果你是拥有一定的面向对象建模思想基础的，那么可以再审视下，你是否有过实现面向对象的软件系统，如果没有，那面向对象的实现能力需要再进一步加强，否则的始终是空有一些想法，感觉不接地气。所以，实践DDD之前，你先要拥有基本的面向对象的建模和代码实现的经历，而这些跟DDD无关，都是一些基本功。
障碍二：缺乏走出DDD第一步的勇气。
为什么说缺乏这个勇气，因为很多时候，我们想完全理解清楚DDD的实践步骤，然后才认为可以动手操作DDD。我们一直觉得，DDD应该跟普通的建模过程有本质的的区别，甚至想在实践过程中完全摒弃传统的建模过程。其实我们撇开DDD不谈，通常的建模过程一般是什么样子的，不也是搞清楚各个关键概念对象，然后再建立他们之间的关系？这个跟DDD本质上是一脉相承的，只是DDD在这个建模过程中，给了我们一些原则，这使得我们在遇到一些问题的抉择时有迹可循。甚至帮助我们在抉择的一开始，就选择一条比较正确的道路。举几个例子：
1.聚合根：
我们一般阻止一个模块跟外部交互时，会怎么做？会选择一组接口跟外部进行交互，外部无法绕过接口对模块内部进行操作。DDD的聚合根起的就是这个作用，只不过它的范围更小，可能是模块内部领域对象之间的一种接口，在模块内部领域对象之间下我们未必能够很好地坚定践行这种接口隔离的原则，那么DDD给了我们相关的经验和原则，聚合根来处理领域对象之间的隔离，能够更好地实践高内聚低耦合的设计原则，能够更好地管理软件的复杂度。
2.核心域：
DDD中特别强调对核心域的投资，核心域的重要性可见一斑。其实核心域就是我们最关心的那部分代码，任何一个软件系统中都存在这样一部分代码的影子，不管你是否刻意这么做。但是我们是否坚持对核心域的呵护？坚决杜绝了外围对核心域的侵蚀？我想未必。所以，从某种程度上讲，DDD给了我们一种信心和方向，让我们更加坚决地维护核心域不被污染，任何情况下都不要妥协。因此如果核心域中出现了一组通用的字符串解析函数，你一定把他们移到通用子域去。如果一个新的领域概念出现了，你一定要毫不吝啬地调整原有的领域模型，将它纳入到核心域。而不是之前的得过且过的凑合心理（只要软件还能够正常运行，那里方便就在那里修改代码）。DDD告诉我们勿以善小而不为，要在原则的指导下做到吹毛求疵的程度。因此，DDD告诉了我们一些需要坚持原则，实现这些原则的方式有很多种，它没有办法一一列举，但是留给我们的就是，要深刻理解它，然后只要践行了这些原则，就是在践行DDD。
3.DDD建模元素：
DDD的所有建模元素未必都要用上，这个要十分清醒。遇到过一些DDD的践行者，总是在谈论，你看我怎么没有用到工厂，怎么没有用到值对象，我这能算是在使用DDD吗？是不是对DDD的理解还是有偏差？其实DDD的所有元素，未必都会在同一个场景下用到。DDD大到一个软件系统，再到一个模块，再小到几个函数，都是可以实践的。那如果你的实践对象比较小，当然不会面面俱到地用到所有的建模元素和方法。如果你的实践对象是一个模块，那么你也许用不到module的概念，用不到BC之间的交互，甚至你只需要关注一个核心域（基础实施层一般是系统共用的）。这种情况下，是一个绝佳的机会，让你将全部精力聚焦在核心域的建模上，虽然你也许用不到全部的建模元素和方法。
4.全员参与：
一定要转变观念，转变传统软件开发模式下，一群架构师/SE专职进行模型的创建，然后将完成的软件模型交给另一群开发人员进行实现。这种隔离的软件开发模式，正是DDD所批判的。不管以何种方式，整个软件的开发过程，都应该是SE、架构师、开发人员全程参与的一个过程。
任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须理解软件模型，并且学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并与领域建模专家保持联系。不管是负责建模的人员还是代码实现的人员，都必修有意识地通过Ubiquitous Language及时交换关于模型的想法。做到这点，其实非常困难，我见过的太多团队，要不分工过于明确，导致部门墙的隔阂，要么是由于人员流动性太大，这种建立起来的沟通环境很快被破坏掉。因此做到全员参与，除了技术层面的因素，还涉及到打造团队文化的勇气和决心。
最后再总结一下我个人对DDD的理解，DDD不是简单的之前了解的任何一种建模方法，它更像是一个大杂烩，它只有一个目标，就是理清领域概念及领域概念之间的关系，这点非常重要，当你已经试图去挖掘领域概念的时候，你的软件模型往往不会偏离太远，而不管你是否使用了DDD的全部建模元素和方法，你已经在践行DDD。
网友评论