领域驱动设计001领域模型相关概念基础

 

展现层interface   负责向用户展现信息以及解释用户命令。

应用层application 很薄的一层，用来协调应用的活动。它不包含业务 逻辑。它不保留业务对象的状态，但它保有应用任 务的进度状态。

 

领域层domain 本层包含关于领域的信息。这是业务软件的核心所 在。在这里保留业务对象的状态，对业务对象和它 们状态的持久化被委托给了基础设施层。

 

基础设施层Infrastructure 本层作为其他层的支撑库存在。它提供了层间的通 信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用

 

 

DDD业务举例:

对一个典型的交互型应用，领域和基础设施层看上去会这 样：用户希望预定一个飞行路线，要求用一个应用层中的应用服务 来完成。应用依次从基础设施中取得相关的领域对象，调用它们的 相关方法，比如检查与另一个已经被预定的飞行线路的安全边界。 当领域对象执行完所有的检查并修改了它们的状态决定后，应用服 务将对象持久化到基础设施中

实体

领域实体一定存在唯一标识符，不管其以什么方式呈现(如类实例数据库记录等等)其一定存在唯一标志符信息来唯一确定本身

值对象

包含一个领域对象的某些属性时的例子。我们对某个 对象是什么不感兴趣，只关心它拥有的属性。用来描述领域的特殊 方面、且没有标识符的一个对象，叫做值对象。

【我们考虑一个绘画应用。用户会看到一个画布且他能够用任何宽 度、样式和颜色来画任何点和线。创建一个叫做 Point 的对象类非常 有用，程序会对画布上的每一个点创建这个类的一个实例。这样的 一个点会包含两个属性对应屏幕或者画布的坐标。考虑每一个点都 拥有标识符是必要的吗？它会有延续性吗？看上去与这样一个对象 相关的事情只有它的坐标】这样的对象我们就叫他值对象，在创建时无ID或其他唯一标识符，并且期望通过构造函数创建在生命周期内不发生改变直至被销毁[被垃圾回收]

 

服务：领域中的一些动作看上去却不属于任何域，比如转账，接收账户和转出账户这两个领域的实体类都不适合具有转账这个动作【方法】，由此可见服务通常是多个领域对象的链接点

服务的特征：

     1. 服务执行的操作涉及一个领域概念，这个领域概念通常不属于一 个实体或者值对象。

     2. 被执行的操作涉及到领域中的其他的对象。

     3.操作是无状态的

 

聚合 ：多个实体或值对象的聚合根

工厂：对象的创建者，隐藏复杂对象的创建过程

资源库: 封装了对DB,NOSQL等存储设备的访问细节，从而使领域对象专注于领域逻辑，而不是访问基础设施的实现细节

避免代码迅速扩散到领域层从而难以维护；资源库本身包含了例如DB等基础设施的访问细节，同时接口又非常简单，纯粹的领域模型【如此抽象的术语用mybatis举列: mapper接口是简单的，纯粹的领域模型，mybatis本身还包含configuration这些数据库基础设施访问的细节配置，如果db变更，我们只需要修改sqlsessionfactory对应的datasource配置即可，无需在于领域逻辑中修改所有的jdbc访问信息】

 

 

 

当领域层逐渐复杂的时候，我们可以考虑重构，在领域中建立service，如果涉及的领域过多，我们可以考虑将其拉到上层

application应用层

 

 

 

 

领域层包含了应用到实体和值对象上的业务规则。那些规则通常与 它们要应用到的对象合成一体。在这些规则中，某些只是用来回答 “是”和“否”的一组问题的，某些规则可以被表现成一系列操作 布尔值的逻辑上的操作，最终结果也是一个布尔值。一个这样的案 例是在一个客户对象上执行测试，看它是否符合特定的信用条件。 这个规则可以被表现成一个方法，起名叫 isEligible（），并且可以 附加到客户对象上。但这个规则不是严格基于客户的数据进行操作 的一个简单的方法。评估规则涉及到验证客户的信用，检查他过去 是否支付过他的债务，检查他是否具有足够的余额等。这样的业务 规则可能非常的大，非常复杂，让对象的功能肿胀，不再满足其原 始的目的。在这种情况下我们可能会试图将整个规则移动到应用 层，因为它看上去已经超越了领域层了。实际上，到了重构的时候 了。 规则应该被封装到一个负责它的对象中，这将成为客户的规约，并 且被保留在领域层中。新的对象将包含一系列布尔方法，这些方法 用来测试一个客户对象是否符合某种信用。每一个方法担负了一个 小的测试的功能，所有的方法可以通过组合对某个原始问题给出答 案。如果业务规则不能被包含到一个规约对象中，对应的代码会遍 布到无数的对象中，让它不再一致。 规约用来测试对象是否满足某种需要，或者他们是否已经为某种目 的准备完毕。它也可以被用来从一个集合中筛选一个特定的对象， 或者作为某个对象的创建条件。 通常情况下，一个单个的规约负责检查是否满足一个简单的规则， 若干个这样的规约组合在一起表现一个复杂的规约，例如： Customer customer = customerRepository.findCustomer(customerIdentiy);

Specification customerEligibleForRefund = new Specification( new CustomerPaidHisDebtsInThePast(), new CustomerHasNoOutstandingBalances());

if(customerEligibleForRefund.isSatisfiedBy(customer) {

        refundService.issueRefundTo(customer);

}

在java代码中，四层对应的是包名

例如:

com.renxl.biz                   

                   .interface

                   .application

                   .domain

                   .Infrastructure