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处理；

• 手工操作功能没有小事；

  安全权限

  贯穿始终；

团队

• 沟通、信任 “敬汝代码而惕之”，