领域模型(Domain Model)概要

What

模型：

模型代表了我们所感兴趣的现实或观点的某些方面。模型是一种简化，它对现实进行阐述，只是抽象出与解决手头问题有关的方面而忽略掉有关的细节问题。

领域：

每个软件程序都会与其用户的活动或兴趣相关，用户在其中使用程序的主要环境称为软件的领域。

领域模型：

通过模型将复杂的领域逻辑以模型的概念和模型元素的形式清晰地表达出来。

 

Why

愿景：

弥补需求与设计之间的空档，并为整个软件开发过程提供可遵循的核心。

难点：

建立领域模型不是件容易的事，建立的方法不易掌握，并难于传授。需要领域专家把握领域逻辑，技术人员掌控设计实现，通过不断的迭代来一同推进领域模型。

作用：

领域模型最重要的价值在于提供一种通用的语言，将领域专家与技术人员联系在一起，并成为开发团队成员所使用语言的核心。

模型与实现之间密切的联系使得模型与现实相关并且保证对于模型的讨论分析能够应用于最终产品------可运行的程序。

 

How

分离领域：

把领域对象跟系统的其他功能分离出来，才能够避免将领域概念与其他跟软件技术相关的概念混淆或者在系统的庞大中失去对领域的把握。

      

用户界面层(表示层)：

   负责向用户显示信息，并且解析用户命令。外部的执行者有时可能会是其他的计算机系统，不一定是人；

应用层：

定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题。

这个层所负责的任务对业务影响深远，对跟其他系统的应用层进行交互非常必要，这个层要保持简练。它不包括业务规则或知识，只是给下一层中相互协作的领域对象协调任务、委托工作。

在这个层此中不反映业务情况的状态，但反应用户或程序的任务进度的状态；

领域层(模型层)：

负责表示业务概念、业务状态的信息以及业务规则。尽管保存这些内容的技术细节有基础结构层来完成，但反映业务状态的状态在该层中被控制和使用。这一层是业务软件的核心。

领域模型包括serveice(服务)、entity(实体)、value-object(值对象)以及由此衍生的factory(工厂:提供模型的创建工作)、reposity(仓储:提供对模型的访问接口)。

注意:具体的设施类服务不属于领域模型，比如具体打印以及打印的文件格式等。

基础设施层：

为上层提供通用的技术能力:应用的消息发送、领域持久化，为用户界面绘制窗口等。通过架构框架，基础结构层还可以支持者四层之间的交互模式。

 

模型组成：

主要包括实体、值对象、服务，以及由此衍生出的聚合、工厂、仓储。

       

实体(Entity)：

通过一系列的连续性(continuity)和标识(identity)来从根本上定义的对象。连续性贯穿了对象的整个生命周期，甚至经历多种实现形式。标识为其唯一索引。

 

值对象(Value Object)：

代表了领域的某种描述性特性，并且没有概念性的标识。

服务(Service)：

当领域中的一个重要进程或者转换操作不是实体和值对象本身的职责时，把操作作为一种独立的接口加入模型，并声明为服务。

   领域中的一些概念不能作为模型中的对象来处理，将领域需要的功能强行加给实体和值对象，不仅会破坏模型中对象的定义，而且还会人为地添加没有意义的对象。

 

聚合(Aggregate)：

   以一个实体为根的聚合对象，圈出一个范围，在这个范围中无论对象处于生命周期的哪个阶段，都应该保持不变性。可以包含多个实体和值对象，聚合表示一组领域对象上的强聚集关系。

 

工厂(Factory)：

创建和重组复杂的对象和聚合，并保持对其内部结构的良好封装；

 

仓储(Repository)：

    处理对象生命周期的中部和结束部分，提供查找和提取持久对象的方法，同时把与生命周期管理有关的复杂基础设施封装起来。

 

通用语言：

将领域模型作为通用语言的核心，会在团队交流和软件实现之间搭建桥梁，并发挥核心作用。

 

偶尔的困难可能正是突破到一个更加深入的模型，获得更完美设计的机会。