-- 关于DDD(领域设计)的一些总结: (事件风暴,领域事件,Actor,属性，规则,业务聚合等)
【官网】：无
应用场景
在一个超复杂的业务场景中怎样实现跨职能跨团队快速分析? 当我们需要跨职能促进技术，用于揭示系统或业务流程的有界上下文，微服务，垂直切片，故障点和起点时，我们往往需要用到领域事件驱动的设计。 其中比较主流的方法论是事件风暴，它可以帮助我们提取领域事件，规则，命令，业务边界，业务聚合等基础资源
无
使用须知
需要根据具体的业务场景和实际流程，并且尽可能的在前期让相关的人员参与进来（业务员，业务分析师，研发人员，测试工程师，UI/UX设计，项目管理人员等)
配置步骤
A)术语.
>领域事件(DomainEvent).
<定义>
领域专家所关心的在领域中的一些事件.
<DDD意义>
Eric Evans在《领域驱动设计》中建议开发一个共享域模型，作为领域专家和IT之间的桥梁，它以无处不在的语言编写并由应用程序代码实现.
<核心思想>
1.软件项目的主要聚焦点应该在领域和领域逻辑，不应该直接从需求开始设计数据库表结构。
2.复杂的领域设计应该基于领域模型，领域模型是封装了数据和行为的对象。
3.软件工程核心实质是社会工程，优秀团队的竞争力来源于互相的信任及良好的沟通。DDD强调技术专家和领域专家一起进行创造性的合作，从而可以不断地切入问题域的核心。
<主要阶段>
以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；
由领域模型驱动软件设计，用代码来实现该领域模型。
<主要元素>
发起方: (用户，定时器，第三方系统(System))
命令: 例如（下单，支付）
属性: 以下单的事件属性为例 (用户,店铺,商品，型号，价格,数量)
事件: 例如 (订单已创建，订单已支付) //订单已创建是有用户发起的，订单已支付是由第三方系统回调发起的)
规则(Policy): 30分钟未支付自动取消订单.
[注]事件风暴这一个实现DDD的方法论中，经常将发起方，命令，事件，规则作为4种基本元素.分别用一些不同颜色的贴纸来表示。
<常用架构>
领域事件可以是一种基于事件的架构。事件架构的好处是可以把处理的业务解耦，实现系统的可扩展性，提高主业务流程的内聚性.
<常用设计模式>
领域事件可以通过观察者模式和订阅模式进行实现。比较常见的实现就是事件总线.
>事件风暴(Event Storming).
<定义>
Event Storming(事件风暴)，它是一种轻量级的系统分析方法，基于 DDD 的概念，能够为我们梳理系统中的各种相关元素，其中包括了核心的 Aggregate.
<特征和应用场景>
跨职能促进技术，用于揭示系统或业务流程的有界上下文，微服务，垂直切片，故障点和起点.
>业务聚合(Aggregate).
在很多的领域事件中，哪些领域驱动事件是内部可以形成闭环，且可以独立访问的. 那么这个东西就是一个业务聚合，也就是聚合根。
例如在电商业务中：
订单（已创建，已支付/已取消，已关闭)
库存（已更新库存，已锁定，已扣减/已恢复)
货物( 已派单，已发货，已签收)
....
>观察者模式与发布/订阅者模式.
常见问题
快速入门
1)通过事件风暴来实践DDD领域设计.
- 参加人员: 条件许可的情况下应该全员参与，包括系统开发人员，业务分析师，业务人员，测试工程师，UX 设计师，项目管理人员等。
- 场地要求: 场地尽可能的大，关键是要有一面长 4 米左右的墙壁，用来悬挂或是黏贴纸张。
- 其他物料: 在进行事件风暴的过程中还需要准备以下的材料:
通过在便签上创建一系列域事件来描述业务流程。用于域事件的最常用颜色是橙色。DomainEvent是以过去时态表示的动词，表示域中的状态转换。在橙色便利贴上写下DomainEvent 的名称。
将粘滞便笺按从左到右的时间顺序放在建模表面上。在您进行风暴会议时，您会发现现有业务流程中存在问题。用紫色/红色的笔记清楚地标记这些。使用垂直空间表示并行处理。
发布所有事件后，专家将发布本地有序的事件序列并强制执行时间表。执行时间线会触发期待已久的对话，最终会出现结构STRUCTURE的设计概念 。
这些事件块或常见分组为我们提供了我们的名义服务候选者（参与者或聚合体，取决于团队对DDD定义的严格程度）。这些将在Boris演习期间使用。
<预期产出1:找出命令>
<预期产出2:确定领域聚合>
找出领域名词
通过分析前一步产生的领域事件寻找领域名词，规则如下：
识别事件中有业务含义的名词；
将含有相同名词的事件合并；
确保名词代表的业务概念清晰完整且没有歧义；
用大黄色即时贴进行标记。
