《领域驱动设计-软件核心复杂性应对之道》阅读笔记（二）

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

第4章 分离领域

4.1模式:LAYERED ARCHITECTURE

在面向对象的程序中，常常会在业务对象中直接写入用户界面、数据库访问等支持代码。而一些业务逻辑则会被嵌入到用户界面组件和数据库脚本中。这么做是为了以最简单的方式在短期内完成开发工作。
如果与领域有关的代码分散在大量的其他代码之中，那么查看和分析领域代码就会变得异常困难。对用户界面的简单修改实际上很可能会改变业务逻辑，而要想调整业务规则也很可能需要对用户界面代码、数据库操作代码或者其他的程序元素进行仔细的筛查。这样就不太可能实现一致的、模型驱动的对象了，同时也会给自动化测试带来困难。考虑到程序中各个活动所涉及的大量逻辑和技术，程序本身必须简单明了，否则就会让人无法理解。
要想创建出能够处理复杂任务的程序，需要做到关注点分离——使设计中的每个部分都得到单独的关注。在分离的同时，也需要维持系统内部复杂的交互关系。
软件系统有各种各样的划分方式，但是根据软件行业的经验和惯例，普遍采用LAYERED ARCHITECTURE(分层架构)，特别是有几个层基本上已成了标准层。分层这种隐喻被广泛采用， 大多数开发人员都对其有着直观的认识。LAYERED ARCHITECTURE的基本原则是层中的任何元素都仅依赖于本层的其他元素或其下层的元素。向上的通信必须通过间接的方式进行。
分层的价值在于每一层都只代表程序中的某一特定方面。这种限制使每个方面的设计都更具内聚性，更容易解释。当然，要分离出内聚设计中最重要的方面，选择恰当的分层方式是至关重要的。在这里，经验和惯例又一次为我们指明了方向。尽管LAYERED ARCHITECTURE的种类繁多，但是大多数成功的架构使用的都是下面这4个概念层的某种变体。

4.1.1 将各层关联起来

各层之间需要互相连接。在连接各层的同时不影响分离带来的好处，这是很多模式的目的所在。
各层之间是松散连接的，层与层的依赖关系只能是单向的。上层可以直接使用或操作下层元素，方法是通过调用下层元素的公共接口，保持对下层元素的引用(至少是暂时的)，以及采用常规的交互手段。而如果下层元素需要与上层元素进行通信(不只是回应直接查询)，则需要采用另一种通信机制，使用架构模式来连接上下层，如回调模式或OBSERVERS模式。
对我们而言，只要连接方式能够维持领域层的独立性，保证在设计领域对象时不需要同时考虑可能与其交互的用户界面，那么这些连接方式就都是可用的。
通常，基础设施层不会发起领域层中的操作，它处于领域层“之下”，不包含其所服务的领域中的知识。事实上这种技术能力最常以SERVICE的形式提供。例如，如果一个应用程序需要发送电子邮件，那么一些消息发送的接口可以放在基础设施层中，这样，应用层中的元素就可以请求发送消息了。这种解耦使程序的功能更加丰富。消息发送接口可以连接到电子邮件发送服务、 传真发送服务或任何其他可用的服务。但是这种方式最主要的好处是简化了应用层，使其只专注 于自己所负责的工作：知道何时该发送消息，而不用操心怎么发送。
应用层和领域层可以调用基础设施层所提供的SERVICE。如果SERVICE的范围选择合理，接口设计完善，那么通过把详细行为封装到服务接口中，调用程序就可以保持与SERVICE的松散连接， 并且自身也会很简单。
然而，并不是所有的基础设施都是以可供上层调用的SERVICE的形式出现的。有些技术组件被设计成直接支持其他层的基本功能(如为所有的领域对象提供抽象基类)，并且提供关联机制(如 MVC及类似框架的实现)。这种“架构框架”对于程序其他部分的设计有着更大的影响。

4.1.2 架构框架

略~

4.2 领域层是模型的精髓

现在，大部分软件系统都采用了LAYERED ARCHITECTURE，只是采用的分层方案存在不同而已。许多类型的开发工作都能从分层中受益。然而，领域驱动设计只需要一个特定的层存在即可。 领域模型是一系列概念的集合。“领域层”则是领域模型以及所有与其直接相关的设计元素的表现，它由业务逻辑的设计和实现组成。在MODEL-DRIVEN DESIGN中，领域层的软件构造反映 出了模型概念。
如果领域逻辑与程序中的其他关注点混在一起，就不可能实现这种一致性。将领域实现独立出来是领域驱动设计的前提。

4.3 模式：THE SMART UI“反模式”

在项目中，人们经常会 尝试分离用户界面、应用和领域，但是成功分离的却不多见，因此，分层模式的反面就很值得一谈。 许多软件项目都采用并且应该会继续采用一种不那么复杂的设计方法，我称其为SMART UI (智能用户界面)。但是SMART UI是另一种设计方法，与领域驱动设计方法迥然不同且互不兼容。
如果一个经验并不丰富的项目团队要完成一个简单的项目，却决定使用MODEL-DRIVEN DESIGN以及LAYERED ARCHITECTURE，那么这个项目组将会经历一个艰难的学习过程。团队成员不得不去掌握复杂的新技术，艰难地学习对象建模。(即使有这本书的帮助，这也依然是一个具 有挑战性的任务!)对基础设施和各层的管理工作使得原本简单的任务却要花费很长的时间来完成。简单项目的开发周期较短，期望值也不是很高。所以，早在项目团队完成任务之前，该项目就会被取消，更谈不上去论证有关这种方法的许多种令人激动的可行性了。
即使项目有更充裕的时间，如果没有专家的帮助，团队成员也不太可能掌握这些技术。最后， 假如他们确实能够克服这些困难，恐怕也只会开发出一套简单的系统。因为这个项目本来就不需要丰富的功能。
因此，当情况需要时：
在用户界面中实现所有的业务逻辑。将应用程序分成小的功能模块，分别将它们实现成用户界面，并在其中嵌入业务规则。用关系数据库作为共享的数据存储库。使用自动化程度最高的用户界面创建工具和可用的可视化编程工具。
事实上，不将领域和用户界面分离，则很难运用本书后面所要讨论的方法，因此 在领域驱动设计中，可以将SMART UI看作是“反模式”。然而在其他情况下，它也是完全可行的。 其实，SMART UI也有其自身的优势，在某些情况下它能发挥最佳的作用——这也是它如此普及的原因之一。在这里介绍SMART UI能够帮助我们理解为什么需要将应用程序与领域分离，而且更重要的是，还能让我们知道什么时候不需要这样做。
优点

• 效率高，能在短时间内实现简单的应用程序。
• 能力较差的开发人员可以几乎不经