领域驱动设计学习笔记

第一章：

有效建模的要素

1.早期模型

2.双方的交流的基础

3.充实模型

4.提炼模型

5.认证与推翻

第二章：

1.团队成员应该使用同一种模型语言进行沟通。

2.模型图只是阐明设计要点和框架，细节体现在代码中，文档应该作为语言与代码的补充。

3.模型图不适合用来生成代码，因为这个不能说的太细。

4.文档应该解释模型的概念，帮助指引代码的方向，在代码中能体现的就不用出现在文档中。

第三章：

1.建模人员必须参与开发，开发人员也需要参与建模。

2.模型与代码要同步更新，重构才会更加顺利。

第四章：

1.分层，每层只做自己的事情，下层不依赖上层，上层依赖同层和下层。

2.分离各层的关注点，领域层应该重点关注领域模型，而不需要关心显示和存储问题。

3.为项目选择合适的框架，不求万全之策，用框架来解决难点问题，可以避开不足之处。

4.smartui，反模式，也有些好处，效率高，成本低，模块独立性好，对界面维护容易（不会影响其他功能）。

第五章：

1.Entity关心的是对象的唯一标识。valueobject关心的是对象属性，这些属性尽量设计成不会改变的。

2.非规范化：将valueobject存在在entity所在的同一页上，场景：当访问时间比存储空间更重要时。

3.在分布式环境中，传递副本到各个服务器中，而不是共享，因为传递引用影响性能。

4.service是领域模型中的一种模式，他包含了一些操作，如一些业务管理类。三个特征：

a.这些操作不是实体中的一个自然部分。

b.接口根据领域模型的其他元素定义。

c.操作是无状态的。

5.service不仅在领域层使用，需要与其他层的service区分开。

6.领域层service可以控制领域层暴露的接口粒度。

7.领域驱动设计不一定只用面向对象范式，面向对象对一些处理大量数学问题及全局逻辑控制的领域不太适合，可以采用规则引擎等范式结合，但能够用的好还是比较困难的。

8.尽量不要采用多种范式。如果非要用，注意四大原则。

a.找到合适的模型概念。

b.统一的语言

c.不要一味依赖uml

d.保持对工具（其他范式）的怀疑态度。

第六章：

1.aggregate对外只有一个根，可以将内部的数据通过vo传给外部，这样边界清晰，当要删除根时，可以将其中的所有实体删除，不用担心外部引用。

2.聚合关系中的规则是固定的，否则多进程同时对局部的修改，可能违反总体的规则。也就是对外实现单根，不允许直接修改内部。

3.对象的创建与对象的执行分开，且不能转移给客户，装配应交给factory.factory是领域的一部分。

4.三种factory:根，需要满足另一对象规则，独立factory.

5.某些情况下不需要factory,如不关心多态。

6.将规则放在factory是因为对象创建出来后基本用不到规则，那么放在factory中使创建出来的对象更简单。

7.repository用于封装批量查询。

8.factory与repository区别：factory用于创建新对象，repository用于重建对象。不要讲新对象和就对象混合在一起，这样会很混乱。