《领域驱动设计》读书笔记（2）——分离领域

第二部分 模型驱动设计的构建块

为了让软件与模型始终保持一致，不管实际处理有多么麻烦，都必须运用建模和设计的最佳实践。领域驱动设计的设计风格大部分遵循职责驱动设计原则，尤其是其中的契约式设计的观点，而这些原则和观点都来自于面向对象编程的最佳实践。 领域驱动设计利用分层体系结构来把领域代码从其它代码中分离出来，利用实体，值对象，服务，工厂，聚合，仓库等具有不同职责的几类对象来对领域建模。

第4章 分离领域

和领域模型绑定的代码是最有价值的代码，然而它往往只占有整个项目代码的一小部分，只有把这么小部分的核心代码分离出来，才有可能实现持续地把握模型。

4.1 分层架构

在面向对象的程序中，用户界面（UI）、数据库和其他支持代码，经常被直接写到业务对象中去。在UI和数据库脚本的行为中嵌入额外的业务逻辑。出现这种情况是因为从短期的观点看，它是使系统运行起来的最容易的方式。 当与领域相关的代码和大量的其他代码混在一起的时，就很难阅读并理解了。对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变得不切实际，而且自动化测试也难以使用。如果在程序的每个行为中包括了所有的技术和逻辑，那么它必须很简单，否则会难以理解。 推荐的分层结构是： 用户界面层 -> 应用层 -> 领域层 -> 基础结构层 将一个复杂的程序进行层次划分。为每一层进行设计，每层都是内聚的而且只依赖于它的下层。采用标准的架构模式来完成与上层的松散关联。将所有与领域相关的代码都集中到一层，并且将它与用户界面、应用层和基础结构层的代码分离。领域对象可以将任务的重点放在表达领域模型上，不需要关心它们自己的显示、存储和管理应用任务等内容。这样使模型发展得足够丰富和清晰，足以抓住本质的业务知识并实现它。

4.1.1 层间的联系

上层对下层的通信是简单的，但是要实现下层对上层的通信需要使用一些技巧或者架构模式。为了实现复杂的领域层和应用层及用户界面层的通信，可以采用回调，观察者模式，或者应用MVC架构模式。为了基础结构层提供的功能，有时也需要领域层继承基础结构层的基类。总之，只要它们坚持隔离领域层的原则，这些方法都是可以的。

4.1.2 架构框架

为了简化开发，项目中往往采用一些框架（j2ee, spring, hibernate ...)，如果让领域模型和框架结合得太紧，往往会受到框架的束缚导致建模的困难，最好在框架之上用普通的Java对象来实现大部分的业务逻辑，保证领域对框架的较低的依赖程度。

模型属于领域层

当领域逻辑和程序的其它关注点混合在一起时，要达到一致是很不现实的。隔离领域实现是领域驱动设计的前提。 把领域逻辑嵌入到UI中的所谓的智能UI设计模式，是领域驱动设计的反模式。

转载于:https://my.oschina.net/komodo/blog/919170