关于预先设计

如果没有读战略篇直接看本文的读者肯定会提出关于预先设计的顾虑，毕竟DDD是被敏捷开发圈子认可的一种架构方式，其目标应该是构建架构模型的响应力。而这里给大家的更多是模式化的实现过程，好似从建模到代码一切都预先设计好了。

值得强调的是，我们仍然反对前期设计的大而全（Big-Design-Up-Front，BDUF）。但我们应该认可前期对核心领域模型的分析和设计，这样能够帮助我们更快地响应后续的业务变化（即在核心模型之上的应用）。这不代表着核心领域模型未来会一成不变，或者不能改变，而是经过统一建模的核心部分变化频率较之外部应用会低很多。如果核心领域模型也变化剧烈，那么我们可能就要考虑是否业务发生了根本性的变化，需要建立新的模型。

另外不能忘记我们预先定义的模型也是被局限在一个分解出来的核心问题域里的，也就是说我们并不希望一口气把整个复杂的业务领域里的所有模型都建立起来。这种范围的局限某种程度上也限制了我们预先设计的范围，促使我们更多用迭代的方式来看待建模工作本身。

最后显然我们应该有一个核心团队来守护核心领域模型，这不代表着任何模型的设计和改动都必须由这个团队的人做出（虽然有不少的团队确实是这样落地DDD的）。我们期望的是任何对核心模型的改动都能够通过这个核心团队来促进更大范围的交流和沟通。检验一个模型是否落地的唯一标准是应用这个模型的团队能否就模型本身达成共识。在这点上我们看到很多团队持续通过代码走查（code review）的方式在线上和线下实践基于核心模型的交流，从而起到了真正意义上的“守护”作用，让模型本身成为团队的共同责任。

实践DDD时仍然需要遵循“模型是用来交流的”的这一核心原则。我们希望本文介绍的方法及模式能够帮助大家更容易地交流领域模型，也算是对DDD战略和战术设计的一点补充。