读书_DDD

让领域模型发挥作用.

1,消化知识.

模型-->深层模型.

2,交流及语言的使用.

将模型作为通用语言的骨干.

3,将模型与实现绑定.

模型驱动设计的构建块.

4,分离领域

一般认为,软件行业确定了分层架构作为软件系统关注点分离的首选方案.基本原则是,每一层中元素只能依赖同一层的其它元素,或直接下层元素.

在面向对象的程序中,用户界面(UI),数据库和其他支持代码,经常写在业务对象中.在UI和数据库脚本中嵌入额外的业务逻辑. 这在短期来看是最容易的方式.

当领域相关的代码和大量其它代码混杂在一起时,就很难阅读并理解了. 对UI的简单的改动就会影响业务逻辑. 改变业务逻辑规则就可能需要小心跟踪UI代码,数据库代码或其它程序元素. 实现一致的模型驱动对象变得不切实际. 自动化测试也难以使用.如果程序的每个行为都包含了所有的技术和逻辑,那么它必须很简单,否则会难以理解. 分离还可以有助于分布是系统的部署,可以灵活的把各层放在不同的物理机器上.

用户界面层/

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

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

基础设施层/

将层连接起来而不影响分离给设计带来的好处,是许多设计模式追求的.层是一种松散关联结构,因为设计的依赖是单向的,上层可以直接使用或操作下层元素,这可以通过直接调用下层的公共接口,维护对它们的引用或使用常规的交互方法来完成.但当下层对象需要跟上层对象通信时,我们需要另一种机制,采用架构模式把各层联系起来,如回调或Observer

连接用户界面,应用层和领域层的模式通常是MVC及它的衍生者. 基础架构层通常不在领域层发其动作,这种技术能力通常以服务的方式提供.另一种形式是技术组件设计为直接支持其它层的基本功能.如某某领域对象的具体实现.

在智能UI和分层架构之间还有其它的解决方案,如Fowler的事务脚本. 它不提供一个对象模型,但把用户界面分离出来.

如果一个结构隔离了与领域相关的代码,同时允许内聚的领域设计与系统的剩余部分保持一种松散的关联,那么这就是领域驱动设计. 必须在复杂性和灵活性做出考虑,权衡.

5,软件中的模型描述.

将用来表述模型的模型元素分为4类: 实体/值对象/服务/DomainEvent

一个对象所代表的事物是一个具有连续性和标识的概念,还是只是用来描述事物的某种状态的属性? 这就是实体和值对象的最基本区别.

值对象具有不变性,除了构造方法,其它操作都是无副作用函数.

服务:

如果用行为或操作来描述会比用对象描述更加清晰,那么最好用服务来描述,尽管这与面向对象建模理念稍有抵触. 服务常用来封装技术层的功能,在领域中则用于对必须完成的一些活动建模,但与状态无关.

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

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

操作是无状态的

模块:

将相关领域模型提炼分类，分而治之

将高关联度的模型分组到一个模块以提供尽可能大的内聚（以能完整完成任务为准）

模块是垂直划分(Domain内部)/分层是水平划分

关联,现实世界中存在着大量的多对多双向关系,这种复杂的关联会给程序开发和维护带来很大的困难. 尽可能的约束关联使其反映领域的使用偏向是非常重要的,至少有3中方法可以使关联变得相对简单.

指定一个导航的方向

双向关联意味着只有两个对象同时放在一起才能被理解. 如果应用并不要求双向交互,则指定一个方向则可以简化设计,如国家和元首是典型的1对多双向关联,但我们未必需要查询华盛顿是哪国的元首,仅维护国家到元首的连接通常是足够的.此时,也就不需要单独的元首类了,个人类就可以了.否则需要一个GetCountryOfThePresdent()方法.getNationality()并不能精确体现业务.

加入限定符来有效减少关联的多重性.

国家和元首是典型的1对多关联,但国家某个时期的总统则将关联转为一对一.

清除不必要的关联

如果关联不是任务的本质,或者不能反映模型对象的基本含义,取消它. 不是所有的现实关联都是在类变量中维护的,如账户的交易明细,可以是账户类中保存一个到交易列表的引用; 也可以是在账户中有一个查询交易的方法,而方法去外部存储中查询.提供导航或是依赖查询,是一种设计上的决定,取决于我们在查询的解耦与关联的内聚之间如何权衡.当出现循环引用时尤其需要仔细考虑.

6,领域对象的生命周期

管理对象有两个挑战,

1. 在生命周期维护对象的完整性.

2. 避免模型由于管理生命周期的复杂性而陷入困境.

三个模式来处理这些问题. Aggregate/Factory/Repository

聚合:

根实体具有全局标志,并最终负责对不变量的检查.

边界内的实体具有本地标志,仅在聚合内唯一.

聚合边界外的任何对象仅能引用根实体,根实体可以把内部实体的实例副本传递给外部,但那只是一个副本,已经和聚合不再关联了.

推论,能通过数据库查询得到的只有聚合根,其他只能通过导航关联访问.

聚合内的对象可以持有其它的聚合根.

删除操作必须一次性删除聚合边界的所有对象.

当聚合边界内发生的任何对象修改被提交时,整个聚合的所有不变量必须都被满足.

当一个实体实例可以被多个其它实体实例共享时,它一定是根实体.

工厂:

组件的创建和组装大多与领域概念无关,将创建与操作组合起来是不合适的,最好分离.但有时对象创建是有领域意义的,如"开设银行账户"

仓储:

工厂封装了对象在创建和重建时的生命周期,还有一种变迁,它在技术上的复杂性也会导致领域设计陷入混乱,那就是对象和存储的双向转换,这种转换是另一种领域设计构造---仓储.

工厂创建新的对象,仓储寻找旧的对象,仓储让客户觉得那些对象好像就在内存中.

Specification/isSatisfiedBy(T)/ Pattern,

Query Objects Pattern,refer to JPA CriteriaQuery,Predicate....

7,使用语言:扩展示例 货物运输系统

8,突破

模型的重构:微重构/模式重构/模型重构

细微的改进,连续的每次精化使我们对模型的理解节节进步.我们必须努力消化领域知识,并提炼出一套稳定通用语言,着眼于根本,得到深度模型.

9,隐含概念转变为显式概念

深层模型包含领域的中心概念和抽象,能够简洁灵活的表达用户活动,问题及解决方案的本质知识.

如何建模不太明显的概念

显式的约束/作为领域对象的流程/规格

Specfication用于3个目的: 验证一个对象/从集合筛选对象/在创建对象时指定该对象必须满足的要求.

10,柔性设计

软件最终目的是为用户服务,但它必须首先为开发人员服务.

设计灵活的东西,往往是简单的,但简单不是唾手可得的.

释意接口Intention Revealing Inteface 类和操作应该表达出其效果和目的,名字需要与通用语言一致.这也是封装的目的,无须理解组件的实现即可通过名字获悉组件的含义.

无副作用函数. 返回结果而不产生副作用. 值对象可以在查询中创建出来,返回给调用者,然后删除.

命令,确保引起状态改变的方法不返回任何领域数据,并尽可能的简单. 可以使用断言或单元测试规范契约.

如果一个操作把逻辑(或计算)与状态修改混在一起,那么应该重构为两个分离的操作. 但这只是针对实体,值对象就不会有命令操作.

修改变元(参数)是个糟糕的行为,只在必要的时候使用,一定考虑命名,且不要既输入又输出.

软件与现实的不同是,拷贝操作没有副作用. 用多个对象构建一个复合对象时,源对象可以不变,复制一份而构建新对象或只是根据源对象某些属性构建.使用副本或是源对象引用取决于领域逻辑,当模拟混合两桶颜料,得到混合颜料时,领域关注混合颜料结果,甚至原来颜料状态,但不关注后来的颜料桶是否空了. 这时可以将源颜料体积相加,颜色配比,生成新颜料,但源颜料不发生变化. 当软件模拟订单采购时,Order.fill(wareHouse),wareHouse就必须减少库存. 领域关注源对象.

概念轮廓

操作封闭

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!