如果你了解"模型"的定义是对现实的有选择性的精简，然后用这样的观点去读 DDD 这本书，你就会发现，DDD 其实没有什么太多的新鲜玩意，它更多地是可以看作是面向对象思潮的回归和升华。在一个"万事万物皆对象"的世界里，哪些对象是对我们的系统有用的？哪些是对我们拟建系统没有用处的？我们应该如何保证我们选取的 模型对象恰好够用？ 在 DDD 以及传统 OO 的观点中，业务而不是技术是一个开发团队首先要关注的内容，众多的框架和平台产品也在宣称把开发人员解放出来，让他们有更多的精力去关注业务。但是，当我们真正去看待时，会发现，开发人员大多还是沉溺于技术中，对业务的理解和深入付出的太少太少。其实要解决这个问题，就要先看清楚我们提炼出来的模型,在整个架构和整个开发过程中所处的位置和地位。我们经常听到两个词，一个是 MDD（模型驱动设计），一个是MDA（模型驱动架构）。如果 DDD 特别关注的是"M"(以及其实现)，那么，这个M应该如何与架构和开发过程相融合呢？我经常会看到我们辛苦提取出来的领域模型被肢解后，分散到系统的若干角落。这真是一件可怕的事情，因为一旦形成了"人脑拼图"，就很难再有一个人将它们一一复原，除非这个人是个天才。