> 为什么采用DDD领域驱动？

- 一句话来说就是解耦，便于扩展。领域驱动也是目前正流行的微服务的前提条件之一。
> 2019年的智能照明版属于DDD领域驱动吗？

- 2019年的智能照明版中包含了一些DDD的设计思想。比如洋葱头式由内而外的分层；比如用到了MediatR, 是中介者模式的体现，里面包含了Command和对应的Handler；比如CQRS的思想......这些都是DDD的重要思想。但是，2019年的这个版本并没有实践出DDD的精髓。在DDD的设计中，领域模型必须具有松耦合、原子性的特点。所谓的松耦合是指领域实体之间的关系。在2019年的这个版本中是强耦合，领域实体基本上和数据库表是一一对应关系，表和表之间存在外键约束。当系统不断扩展的时候，这种强关系会让领域关系变得纠缠不清。另外，在涉及多表操作的时候，2019年的这个版本有时会通过事务来处理，即通过代码维护领域关系。而真正的DDD会把事务内嵌在Aggregate中。所谓Aggregate有且只有一个聚合根Aggregate Root。

- 洋葱头式由内而外的分层：
  -  核心层是与领域或技术无关的基础构件块，它包含一些通用的构件块。
  - 领域层（Domain）是业务逻辑的地方，每个类的方法都是按照领域通用语言中的概念进行命名
  - API层是领域层的入口，它使用领域中的术语和对象
  - 基础架构（Infrastructure）层是最外部的一层，它包含了对接各种技术的适配器，例如数据库、用户界面以及外部服务。

- CQRS的思想：CQRS，全称Command Query Responsibility Segregation。直译过来就是命令查询的职责分离。
  - Command指的是增加/更新数据的处理。
  - Query指的是查询数据的处理。它不会造成数据的变更

> Aggregate 

- 是一种模式，在代码中实现的具体形式很简单
  -  定义一个Entity，作为Aggregate Root，称之为聚合根
  - 遵循Aggregate的完整性规则对领域数据进行操作

- Aggregate的完整性规则
  - 所有的代码只能通过 Aggregate Root，即聚合根这个特殊的 Entity 访问系统的 Entity，而不能随便的操作任一的 Entity。
  - 每个事务范围只能更新一个 Aggregate Root 及它所关联的 Entity 状态。

  
> Event Storming
- 我们听说过"头脑风暴"，大致是让团队成员一起参与讨论出主意。在DDD中，Event Storming，事件风暴，是让领域专家(熟悉业务的人)、技术人员、产品经理等齐聚一堂，用大家都可以理解的形式表达业务逻辑。通常来说，会在一个比较空的房间内腾出一面墙，大家把想法通过便签贴到墙上。

- 举一个例子：假设用户在某个系统中发布信息，Event Storming中的关键要素大致包括：
  - Event：触发领域状态改变的动作。比如这里叫，NewsPublished
  - Aggregate：这里的消息就是领域实体。比如这里叫，News
  - Command: 所有领域状态的改变，肯定是用户通过系统界面发出的，用户从界面发出的指令叫Command(还记得MediatR中的xxxCommand:IRequest<T>, xxxCommandHandler<TResult, T>吗？这里的IRequest接口就代表着用户发出的Command,每个Command都有响应的Handler)
  - User：操作系统的用户或角色
  - Information：用户发出Command信息需要基本的前提信息


- 如果我们能清晰地知道Command, Command所需要的Information, 是哪个用户或角色执行Command, 对那个Aggregate执行Command, 以及Event是什么，那基本上所有相关人员对系统的业务逻辑已经做了比较清晰的、统一的描述。

# 用ProcessOn报警写报警版的Event Storming
  - 报警相关的发生在Warning Aggregate上。Aggregate用浅黄色表示
  - 事件（Event）用橙色表示 。事件的一般形式为：Aggregate+动词过去式
  - Command, 浅蓝色，一般形式为：动词+Aggregate
  - 备注用紫色表示
  -  用浅绿色来表示读模型。与 CQRS 的 Query 含义相同

- 根据APP界面，报警被创建后，用户申请维修，这时系统会查询用户的报警套餐(User Pacakge), 这里又出来一个User Package的Aggregate，而且由于是查询，返回的是Read Model(一般用绿色), Read Model交给界面
- 这个界面上有两种可能，一个是用户套餐中的免费维修次数还有，另一个是免费维修次数用完了。如果还有维修次数，用户确认。如果没有维修次数，用户查询所有套餐(Packages)，再次Read Model和界面。

> 报警首页

>报警相关
- 系统->Create Warning(Command)->Warning(Aggregate)->Warning Created(Event)->当前报警
- 用户->ApplyFix(Command)->Warning(Aggregate)
- 系统->Query User Package(Command)->User Package(Aggregate)->User Package Read Model
  - 根据APP界面，报警被创建后，用户申请维修，这时系统会查询用户的报警套餐(User Pacakge), 这里又出来一个User Package的Aggregate，而且由于是查询，返回的是Read Model(一般用绿色), Read Model交给界面
- 用户->Query Pakages(command)->Packages(Aggregate)->Packages Read Model
  - 这个界面上有两种可能，一个是用户套餐中的免费维修次数还有，另一个是免费维修次数用完了。如果还有维修次数，用户确认。如果没有维修次数，用户查询所有套餐(Packages)，再次Read Model和界面。
- 用户-> Confirm Apply Fix(Command)->Warning (Aggregate)->Warning Apply Fix Confirmed(Event)
- 客服->Dispatch Warning(Command)->Warning(Aggregate)->Warning Dispatched(Event)
- 电工-> Accept Warning（command）->Warning->Warning Accepted(Event)
- 电工-> Confirm Warning Repair->Warning->Warning Repair Confirmed(Event)
- 系统->Finish Warning->Warning ->Warning Finished(Event)

# 开关管理
> 位置分类相关
- 安装人员-> Create Electric Box(Command)->Electric Box(Aggregate)->Electric Box Creted 
- 安装人员-> Create Category(Command)->Category用途(Aggregate)->Category Creted 
- 安装人员-> Create Line Type(Command)->Line Type开关类型(Aggregate)->Category Line Type
- 安装人员->  Add Mac To Electric Box(Command)->Mac(Aggregate)->Mac Added To Electric Box(Event)
- 安装人员->  Add Line To Category(Command)->Line线路（Aggregate)->Lined Added To Category(Event)
- 安装人员->  Add Line To Line Type(Command)->Line线路（Aggregate)->Lined Added To Line Type(Event)
- 安装人员->  set Line (Command)->Line线路（Aggregate)->Line Set(Event)

> 场景
- 安装人员+用户 TimingInfo+LineInfo（Read model）->Create Scene(Command)->SCene(Aggregate)->Scene Created(Event)


> 电费和套餐

- 管理员->Set User Package->User Package->User Package set
- 管理员->Set User Electricity Type-> User Electricity Type-> User Electricity Type set
- 管理员-> Set Fixed Electricity->User Fixed Electricity->User Fixed Electricity Set
- 管理Set High Low Electricity ->User High Low Electricity->User High Low Electricity Set
- 管理员-> Set Step Electricity->User Step Electricity->User Step Electricity Set






> 领域设计
- 所有的领域应该有一个抽象基类，而且是一个泛型类。
```
public abstract class Entity<T>
{
  public T Id{get;protect set;}

}
```
-  DDD中有一个很重要的概念 ，叫做Object Value（值对象）。会把一个Aggregate里的对象类型看作是值类型。这样做一方面是减少Aggregate对关系的依赖，一方面可以很好判断Aggregage的状态。同样也是一个泛型抽象基类，如果一个Object类型的对象想要被当作值类型处理，那就继承这个泛型抽象基类。