《领域驱动设计——精简版》随笔——分层架构

    在面向对象的程序中，用户界面(UI)、数据库和其他支持代码，经常被直接写到业务对象中去。在UI和数据库脚本的行为中嵌入额外的业务逻辑。出现这种情况是因为层短期的观点看，它是使系统运行起来的最容易的方式。

   当与领域相关的代码和大量的其他代码混在一起时，就很难阅读并理解了。对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI 代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变都不切实际，而且自动化测试也难已使用.如果在程序的每一个行为中包括了所有的技术和逻辑，那么它必须很简单，否则会难以理解。

 

    在一个复杂的程序进行层次划分。为每一层进行设计，每层都是内聚的而且只依赖于它的下层。采的用标准的架构模式来完成与上层松散关联。将所有与领域模型相关的代码集中在一层，并且家它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上，不需要关心他们自己的显示、存储和管理应用任务等内容。这样使模型发展得足够丰富和清晰，足以抓住本质的业务知识并实现它。

典型的企业应用架构由下面四个概念上的层组成：

1. 用户界面（表现层）：负责给用户展示信息，并解释用户命令。
2. 应用层：该层协调应用程序的活动。不包括任何业务逻辑，不保存业务对象的状态，但能保存应用程序任务过程的状态。
3. 领域层：这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。
4. 基础设施层：对其它层来说，这一层是一个支持性的库。它提供层之间的信息传递，实现业务对象的持久化，包含对用户界面层的支持性库等。

让我们更详细地看一下：

 

1.用户界面层

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

2.应用层

    定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题。这个层附负责的任务对业务影响深远，对跟其他系统的应用层进行交互非常必要。这个层要保存简练。它不包括处理业务规则或知识。只是给下一层中相互协作的领域对象协调任务、委托工作。在这个层次中不反映业务情况的状态，但反映用户或程序的任务进度的状态。

• 负责应用中UI屏幕之间的导航，以及与其它系统应用层之间的交互。

• 还能对用户输入的数据进行基本（非业务相关）的验证，然后再把数据传到应用的其它层（更底层）。

• 不包含任何业务、领域相关的逻辑、或数据访问逻辑。

• 没有任何反映商业用例的状态，但却能处理用户会话或任务进展的状态。

 

3.领域层

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

• 负责业务领域的概念，业务用例和业务规则的相关信息。领域对象封装了业务实体的状态和行为。贷款处理应用中的业务实体例子有抵押（Mortgage）、房产（Property）和贷款人（Borrower）。

• 如果用例跨越多个用户请求（比如贷款登记过程包含多个步骤：用户输入贷款详细信息，系统基于贷款特性返回产品和利率，用户选择特定的产品/利率组合，最后系统会用这个利率锁定贷款），还可以管理业务用例的状态（会话）。

• 包含服务对象，这些服务对象只包含一个定义好的、不属于任何领域对象的可操作行为。服务封装了业务领域的状态，而业务领域并不适用于领域对象本身。

• 是商业应用的核心，应该与应用的其它层隔离开来。而且，它不应该依赖于其它层使用的应用框架（JSP/JSF、Struts、EJB、Hibernate、XMLBeans等）。

 

4.基础结构层

    为上册提供通用的技术能力；应用的消息发送、领域持久化，为用户加盟绘制窗口等。提供架构框架，基本结构层还可以支持这四层之间的交互模式。