DDD理解
DDD体现的是对现实的充分尊重。
1.尊重业务现实，领域专家、领域语言等概念
2.尊重团队现实
3.尊重变化
Application
- 对某一业务线的整体掌控，流程组装，进度管理，存储时机掌控。
- 依赖外部模块的业务环节实现；
- 尽量满足UI需求；
- 落地：uow提交；
Domain
- 业务线视作水平线的话，此处应在垂直方向上切分各业务线，重新整合抽象，处理具体的业务环节、业务步骤。
- 划分范围、确定职责，需要多维度多视角的考虑抽象；
- 粒度尽量小。
- 本质上是对业务逻辑处理过程的纯化，能用的技术手段实质上是受限的；
- 不要考虑业务逻辑跨项目跨产品的通用性，这是以后的事；
- 缓存和仓储需要注意，有必要的话分开；
- 落地：尽量少的执行 存储，最好没有；
在内存中处理逻辑；
尽量使用private set;
尽量避免锁与线程操作；
注意时间、时刻及引用的问题；
存储、查询
- 存储的重要性仅次于Domain。
- 存储的隔离有两种，一种仅隔离不同的数据库，一种连ORM也隔离开；
- 大多数情况下不需要隔离ORM，技术选型确定后，使用时不必有过多顾虑；
- 如果使用EFCore这种ORM，DbSet和DbContext可以进入Domain；
- 查询与存储关联非常紧密同时距离用户很近（两个地狱），技术手段可以放宽，存储过程、Db函数，lua脚本之类都可以考虑；
- Domain可以对查询进行一些适配，或优化（后期）；
- 快照时机，快照性能；
- 实时、非实时查询；
- 复杂报表需要自行适配业务数据；
命令、事件、消息。。。
- 总线队列比较容易被接受；
- 事件可以分阶段落地；
- 就算是日志也要养成记录快照的习惯；
标识
- 避免自增Id；
- 分布式id，大部分时候可以使用CombineGuid（唯一、基本有序、随机、提前生成）；
- 进行事件快照时可以使用同一id，不同事件类型进行处理。
- 通常会发生变化的对象需要一个标识。
实体与值对象
- 实体属性会产生变化用于描述记录业务生命期内的各种事件，实体本身及引用的实体都会变化，实体间的关系通常使用引用来表达；
- 值对象本身是偏概念的东西，用过函数语言的会比较容易理解，在c#中与之类似的有元组、匿名类和提案里的record；
- 这里最重要的是思想的引入而非手段。
- 值对象本身表达的是部分属性的快照副本，类似于实体拥有的所有属性上的一段切片，是某个时刻下的一小段副本，所以不需要标识也只能是只读的；
- 属于使用者/调用者关注的东西，如果没有人关注它，通常没有必要单纯为表达某个概念而增加，容易造成概念混乱；
- 实体的变化会使逻辑处理产生隐患，尤其是涉及到引用类型时，这时引入值对象的快照副本概念就会很自然，比如使用一些变量取出属性值，或者一个匿名类用于方法内部，或者在方法的参数上仅提供值类型的参数，总之“逻辑算法仅能处理当前时刻的对象状态” 这一层概念必须明确表达。
- 实体的逻辑处理通常会导致实体自身属性的变化，业务上对实体属性的变化通常很敏感，有时不能仅提供一个结果给需求方，这时我们就需要增加一些属性记录下结果产生的原因。
- 值对象不在于我们定义的类型结构，而是要帮助技术人员建立起值的概念，快照副本及当前时刻是关键点，这种概念的建立非常有助于理解业务事件；
------------------------------------------------------------------上面是值对象值的部分，下面是对象部分（结构，属性包）； - 有时候我们的逻辑中会有“我不关心是什么类型的实体，我只关心是否符合某种结构（属性包，形状）”，也就是实体在不同视角下的形状，关注点产生了变化。
- 一般在一些横切式的模块或者分析类的模块中有应用。
- 字典、配置类使用实体，更新原状态，插入新记录。
后台
系统后台：监控，分布式管理。。。；
- 管理后台不可直接引用Domain自行组装业务流（使用接口）；
- 管理后台的需求必须与业务线需求一同交给Domain处理；
-
手工操作功能没有小事；
安全权限
贯穿始终；
团队
- 沟通、信任 “敬汝代码而惕之”，