DomainDrivenDesign

韩陈昊

如果让我用简练的词汇描述 DDD 的中心思想。我的回答是 "关注精简的业务 模型及实现的匹配"。DDD 其实没有什么太多的新鲜东西，它更多地是可以看作是面向对象思潮的回归和升华。在一个"万事万物皆对象"的世界里，哪些对象是对我们的系统有用的? 哪些是对我们拟建系统没有用处的?我们应该如何保证我们选取的模型对象恰好够用?

各种对象并不是独立存在的，它们之间有着千丝万缕的联系。这种扯不断理还乱的联系构成了系统的复杂性。一个具体的体现就是，我们修改了一处变更，结果引发了一系列的连锁反应。虽然对象的封装机制可以帮我们解决一部分问题，但那只是有限的一部分。我们应该如何在一 个更高点的层次上，通过保留对象之间有用的关系去除无用的关系，并且限定变更影响的范围以来降低系统的复杂度呢?

在 DDD 以及传统 OO 的观点中，业务而不是技术是一个开发团 队首先要关注的内容，众多的框架和平台产品也在宣称把开发人员解放出来，让他们有更多的精力去关注业务。但是，当我们真正去看待时，会发现，开发人员大多还是沉溺于技术中，对业务的理解和深入付出的太少太少。其实要解决这个问题，就要先看清楚我们提炼出来的模型 ,在整个架构和整个开发过程中所处的位置和地位。 我们经常听到两个词，一个是 MDD (模型驱动设计) ， 一个是 MDA(模型驱动架构)。如果 DDD 特别关注的是 "M"(以及其实现)，那么，这个 M 应该如何与架构和开发过程相融合呢?我经常会 看到我们辛苦提取出来的领域模型被肢解后，分散到系统的若干角 落。这真是一件可怕的事情，因为一旦形成了"人脑拼图"，就很难再有一个人将它们一一复原。