分离领域

在软件中，专门用于解决领域问题的那部分通常只占整个软件系统的很小一部分，这与其重要性远远不成比例。要想实现最佳的设计构思，旧的去研究模型中的元素并且将他满是为一个系统。绝对不能像在夜空中辨认星座一样，勉强把领域对象从许多对象中挑选出来。我们需要将领域对象与系统中的其他功能分离。这样就能够避免将领域概念和其他至于软件技术相关的概念想混淆。也不会把领域与整个软件系统混为一谈。

分离领域的复杂技术早已出现，而且都是我们耳熟能详的，但是他对于能否成功用建模原则起着非常关键的作用，所以我们要从领域驱动的视角对他进行简要的回顾。

 

模式：Layered Architecure

 

在一个运输应用程序中，要想支持从城市列表中选择运送货物目的地这样的简单用户行为，程序代码必须包括：

 

1. 在屏幕上绘制一个屏幕组件（widget）；
2. 查询数据库，调出所有可能的城市；
3. 解析并验证用户输入；
4. 将所选择城市与货物关联；
5. 向数据库提交此次数据修改。

上面所有的代码都在同一个程序中，但是只有一小部分代码与运输业务相关。

 

在上面的对象程序中，常常会在业务对象那中直接写入用户界面、数据库访问等支持代码。而一些额外的业务逻辑则会被嵌入到用户界面组件和数据库脚本的行为中。这么做是为了以最简单的方式在短期内完成开发工作。

如果与领域有关的代码分散在大量的其他代码之中，那么查看和分析领域代码就会变得相当困难。对用户假面的简单修改实际上很可能会改变业务逻辑，而要想调整业务规则也可能需要对用户界面代码、数据库操作代码或者其他的程序元素进行仔细的筛查。这样就不太可能实现一致的、模型驱动的对象了，同时也会改自动化测试带来困难。程序中每一个活动都有其自身的逻辑和适用的技术，因此程序本身必须简单明了，否则就会让人无法理解。

 

分割软件系统有各种各样的方式，但是根据软件行业的经验和惯例，普遍采用Layered Architecture(分层架构)特别是有几个层基本上已经成了标准层。

 

用户界面层（表示层）	负责现用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人
应用层	定义软件要完成的任务，并且只会表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道 应用层要尽量简单，不包含业务规则或者知识，而知未下一层中的领域对象协调任务，分配工作，是他们互相协作。他没有反应业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。
领域层（或模型层）	负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是基础设施层实现的，但是反应业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。
基础设施层	为上面各层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。基础设施层还能够通过架构框架来支持四个层次间的交互模式。

 

有些项目没有明显划分出用户界面层和应用层，而有些项目则有多个基础设施层。但是将领域层分离出来才是实现Model-Driven Design的关键。

因此：

给复杂的应用程序划分层次。在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。采用标准的架构模式，至于上层进行松散的连接。将所有与领域模型相关的代码放在一个层中，并把它与用户界面层、应用层以及基础设施层的代码分开。领域对象应该将重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，也无需管理应用任务等内容。这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效地使用这些知识。