领域驱动设计学习笔记

第一章：
有效建模的要素
1.早期模型
2.双方的交流的基础
3.充实模型
4.提炼模型
5.认证与推翻

第二章：
1. 团队成员应该使用同一种模型语言进行沟通。
2. 模型图只是阐明设计要点和框架，细节体现在代码中，文档应该作为语言与代码的补充。
3. 模型图不适合用来生成代码，因为这个不能说的太细。
4. 文档应该解释模型的概念，帮助指引代码的方向，在代码中能体现的就不用出现在文档中。

第三章：
1. 建模人员必须参与开发，开发人员也需要参与建模。
2. 模型与代码要同步更新，重构才会更加顺利。

第四章：
1. 分层，每层只做自己的事情，下层不依赖上层，上层依赖同层和下层。
2. 分离各层的关注点，领域层应该重点关注领域模型，而不需要关心显示和存储问题。
3. 为项目选择合适的框架，不求万全之策，用框架来解决难点问题，可以避开不足之处。
4. smart ui，反模式，也有些好处，效率高，成本低，模块独立性好，对界面维护容易（不会影响其他功能）。

第五章：
1. Entity关心的是对象的唯一标识。value object关心的是对象属性，这些属性尽量设计成不会改变的。
2. 非规范化：将value object存在在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用于重建对象。不要讲新对象和就对象混合在一起，这样会很混乱。