DDD学习之实践性建模与领域服务

我们多的是强调将建模人员完全独立出来，为的充分发挥其能力，专职的负责各个项目的建模，（当然，实际的资源分配强迫我们做某些我们也知道不好的事）我们来学习一下DDD中建言（记住我们还没充足的条件或者资源做到DDD的开发模式）。

即使建模人员对于项目多使用的技术已经十分娴熟，有丰富的项目的经验，但建模人员与实现的完全脱离还好有明显的弊端，“如果写代码的人认为他们不对模型负责，或者并不理解如何让模型在一个应用程序中发挥作用，那么模型对于软件来说根本就没有作用。如果开发人员没有意识到改变代码会同时改变模型，那么他们的重构只会减弱模型的作用而不是增强。其间，当一个建模人员与实现过程相分离的时候，他/她永远不会学会（或者说错过了）对实现上的一些约束的感觉。模型驱动设计的基本约束——模型要支持高效的实现和模型要抽象关键的领域知识——已经丢失了一半，最终模型会变得不再实用。最后，如果分工阻碍了合作，在对模型驱动设计进行编码时，不能传递细节，那么经验丰富的设计人员的知识和技术都不能传递给其他的开发人员。”这些并不意味着团队中不能有专门的角色，正如敏捷过程中会有一些趋于自然出现的非正式专业，在DDD中，代码是模型的一部分，改变代码的同时应该同时对模型做出修改，程序员会充当相当部分的建模工作，将项目组织成有利于程序员建模的形式将更有利。

也因此，“负责建模的技术人员必须花时间接触代码，不管他/她是否在项目中担任主要角色。任何负责代码修改的人员都必须学习通过代码表达模型。每个开发人员都必须参与一些级别的模型讨论中，并于业务专家接触。负责不同工作的人员都必须主动和接触代码的人交流，通过通用语言动态交换模型想法。”

另外，关于领域中模型类型，对于实体entity，主要反映的对象有一系列的连续的变化状态的，也即应用对象，对于值对象，主要描述领域的数据，还有被划分出来的便是服务（不必感觉有违些OO概念），“当领域中的一个重要的进程或转换操作不是实体和值对象本身的职责时，把操作作为一种独立的接口加入模型，并声明为服务。根据模型中使用的语言定义接口，保证操作名是通用语言的一部分。使这个服务变成无状态的。”正如PoEAA提到的服务层（未必就是一层），在必要的时候加入，可以分担一部分领域逻辑（不属于任何实体和值对象的）——因为主要业务逻辑的完成还是通过调用各个领域实体或值对象完成的，并承担起为领域模型定义接口的作用，同时更清晰的划分出应用层和领域层的界限。