分离领域——将各层关联起来

将各层关联起来

到目前为止，我们的讨论主要一种在层次划分以及如何分层才能改进程序各个方面的设计上，特别是集中在领域层上。但是显然，各层之间也需要互相连接。在连接各层的同时不影响分离带来的好处，这是很多模式的目的所在。

 

各层之间是松散连接的，曾与层的依赖关系只能是单向的。山层可以直接使用或操作下层元素，方法是通过调用下层元素的公共接口，保持对下层元素的引用（至少是暂时的）以及采用常规的交互手段。而如果下层元素需要与上层元素进行通信（不只是回应直接查询），则需要采用另一种机制，使用架构模式是来连接上下层，比如回调模式或observers模式。

 

最早将用户界面层与应用层和领域层相连的模式是Model-View-Controller（MVC）框架。他是为Smalltalk语言发明的一种设计模式，创建于20世界70年代。随后出现的许多用户界面架构都是受到他的启发而产生的。

 

还有许多其他连接用户界面层和应用层的方式。对我么而言，只要连接方式能够维持领域层的独立性，保证在实际领域对象时不需要同时考虑可能与其交互的用户界面，那么这些连接方式就都是可用的。

 

通常基础设施层不会发起领域层层中的操作，他处于领域层“之下”，不包含其所服务的领域中的知识。事实上这种技术能力最常以service的形式提供。例如，如果一个应用程序需要发送电子邮件，那么一些消息发送的借口可以放在基础设施层中，这样，应用层中的元素就可以请求发送消息了。这种解耦是程序的功能更加丰富。消息发送接口可以连接到电子邮件发送服务、传真发送服务或任何其他可用的服务。但是种方式最主要的好处是简化了应用层，使其只专注于自己所负责的工作：知道何时该发送消息，而不用操心怎么发送。

 

应用层和领域层可以调用基础设施层所提供的Service。如果Service的范围寻则合理，接口设计完善，那么通过把详细行为封装到服务接口中，调用程序就可以保持与Service的松散连接，而且不会那么复杂。

 

然而并不是所有的基础设施都是以可供上层调用的Service形式出现的。有些技术组件被设计成直接支持其它层的基本功能（比如为所有的领域对象提供抽象基类），并且提供关联机制（比如MVC以及类似的框架实现）。这种“架构框架”对于程序其他部分的设计有着更大的影响。

 

架构框架

如果基础设施通过接口调用Service的形式来实现，那么如何分层以及如何保持曾与层之间的松散连接就是相当显而易见的。但是有些技术问题要求更具侵入性的基础设施。整合了大量基础设施需求的框架通常会要求其他曾以某种特定的方式实现，不如意框架类的子类形式或者带有结构化的方法签名。（子类在父类的上层似乎是违反常理的，但是要记住那个类反映了另一个类的更多知识。）最好的架构框架既能解决复杂技术问题，也能让领域开发人员集中精力去表达模型，而不考虑其他问题。然而使用框架很容易为项目制造障碍：要么是设定了太多的假设，减少了领域涉及的可选范围；要么是需要实现太多的东西，影响开发进度。

 

项目中一般都需要某种形式的架构框架（尽管有时项目团队选择了不太合适的框架）。当使用框架时，项目团队应该明确其使用目的：建立一种可以表达领域模型的实现并且用它来解决重要问题。项目团队必须想方设法让框架满足这些需求，即使这意味着抛弃框架中的一些功能。明智而谨慎的选择框架中最具价值的功能能够减少程序实现和框架之间的耦合，是随后的设计决策更加灵活。更重要的是，现在许多框架的用法都齐齐复杂，这种简化方式有助于保持业务对象的可读性，使其更富有表达力。

 

架构框架和其他工具都在不断发展。在新出现的框架中，越来越多的技术问题会自动得到解决或者被预先设定好解决方案。如果框架使用得当，那么程序开发人员将可以更加专注与核心业务问题的建模工作，这会大大提高开发效率和程序质量。但与此同时，我们必须保持克制。不要总是想着寻找框架，因为精细的框架也可能会束缚住程序开发人员。

 

模型属于领域层

现在大部分软件系统都采用了Layeared Architecture，只是采用的分层方案存在不同而已。许多类型的开发工作都能够从分成中受益。然而，领域驱动设计之需要一个特定的层存在即可。

 

领域模型以一系列概念的集合。“领域层”则是另有模型以及所有与其直接相关的设计元素的表现，他有业务逻辑的设计和实现组成。在Model-Driven Design中，领域层的软件构造反映出了模型概念。

 

如果领域逻辑与程序中的其他关注点混在一起。就不可能实现这种一致性。将领域实现独立出来时领域驱动设计的前提。