领域驱动设计学习笔记
第一章:
有效建模的要素
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用于重建对象。不要讲新对象和就对象混合在一起,这样会很混乱。