领域驱动设计DDD-研究记录

分层设计：User Interface -> Application -> Domain -> Infrastructure

 

领域对象

实体Entity：拥有唯一标识符的对象，一般需要用来持久化

值对象valueObj：不关心他的唯一标识符（也就是不存在），只关心他属性的对象。极力推荐值对象是不可变的，由构造器创建

服务：些领域中的动作，它们是一些动词，看上去却不属于任何对象，通常跨多个对象；服务也分层，比如：应用服务、领域服务

模块Module：模型越来越大，将达到一个作为整体很难讨论的点。将模型组织进模块，被用于组织相关概念和任务以降低复杂性，增加内聚性，降低耦合度；模块应该由在功能上或者逻辑上属于一体的元素构成

聚合Root：用来定义对象所有权和边界的领域模式。每个聚合有个根，它是外部可以访问的唯一对象，这意味着其他对象不能对根内的对象进行操作，只能让根来执行某些活动；如果根被删除，根内的所有对象都要被删除；如果聚合根被简历，他的所有内部对象都将被建立，如果一个对象不能被正常创建，将产生一个异常；如果要把根内部对象传递给外部，可以做一份拷贝，这些保证对拷贝的修改不会影响聚合的一致性；如果聚合对象被保存到数据库，只有根可以通过查询来获得，其他对象只能通过根导航关联来获得。聚合内的对象可以允许持有其他聚合类对象的根引用。

工厂Factory：帮助处理对象的创建。实体和聚合可能会很庞大和复杂，通常某些事物通常是有其他事物创建的，所以需要工厂的来创建。通过构造函数来创建和领域本身是冲突的，相当于让客户端来维护领域内的关系和规则，这相当于让领域内的一部分责任转移到了外部（就像给我们轮子、引擎，让我们自己取构造汽车）。

资源库Repository：处理对象的存储问题，封装所有获取对象引用所需要的逻辑。是领域模型的范畴，会调用基础设施。

 

服务的3个特征：

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

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

3.操作是无状态

 

其他意识

应用层是很薄的一层，他可以调用领域层，也可以直接调用基础设施层

调用领域层必须经过应用层

领域对象之间的关联应该尽量消除

脱离了模型设计会导致软件不能反映它所服务的领域

建模的第一件事是阅读业务规范，从中寻找名词和动词。名词被转化为类，动词被转化为方法。

把约束、过程、规约放在一个方法中，如果比较复杂就放在应用层

防奔溃层：Facade，每个Facade增加一个适配器Adapter