DDD领域驱动设计---战略设计（包括四色原型建模）

      相当于策略设计，从宏观角度着眼于领域的分析设计，属于系统分析阶段，注重如何从有界上下文中寻找领域模型，战略模式由有界上下文、无所不在的语言和上下文映射组成。

     在战略设计前首先要了解下领域知识、业务策略、业务规划。

       1、有界上下文：是指再空间或时间上有边界的一段环境背景，它确定了每个模型的适用范围，模型体现了这个范围内的逻辑一致性。

       2、统一语言：统一语言必须在领域模型中表达出来，主要体现在领域模型中的名称上。不应只由业务专家或是其他单一职位定义，而应团队人员共同商定。

       3、上下文映射组成（上下文关系）:

              a、共享内核（例如两个团队共享一份类库）此种方式很少用，耦合度太高。

              b、开发主机服务也就是上下游关系映射或API调用，一个服务通过RPC等同步方式调用另一个上下文的API，这种目前比较普及。

              c、发布\订阅模式：一个发布，一个订阅，只依赖事件或消息，使得两者之间最大化松耦合。   

              d、发布语言（Published Language）:两个有界上下文中的模型沟通的语言表达方式。例如XML,JSON

       康威第一定理（Conways Law）：组织性质决定架构。即系统架构代表实现系统的组织的沟通结构，对于软件中的每个模块，都对应有一个组织单元；组织单元之间存在沟通依赖，软件中对应的模块之间同样存在依赖关系。

       在领域（独立的产品或是项目）中划分{核心子域（业务策略和业务规则重点实施地），支持（辅助）子域，通用子域。}（具体的项目）每个域确定上下文（领域边界）

       最佳实践：一个有界上下文对应一个子域，对应一个团队，对应一个微服务。

       DDD建模基本上只需要三种UML图：用例图（表达需求用例）、序列图（模拟领域中的逻辑流程，能够记录和验证逻辑）、类图（表达类与结构关系）。

划清领域上下文的方法：

      1、通过领域故事（Domain Storytelling）的方式，专注于领域知识，通过领域语言来探索和理解用户流程、工作程序和整体业务流程和规则。

     例如：问：“你的工作做什么的？”

                答：“进行货运计划调度”

                问：“具体怎么回事？”

                答：“举个例子，客户需要托运一批货物，然后需要让路线小组规划路线，机场小组再分配计划，最后指定机位。”

                这里“客户需要托运一批货物”主语是“客户”，谓语动词“托运”，宾语是“货物”。可以使用不同颜色表示他们：黄色是主语，粉红色表谓语，蓝色表示宾语，具体颜色取决自己，也可参考下面的四色原型。

     2、还有填写表格法和事件风暴会议发现有界上下文。

本环节最主要的就是划清领域上下文。也是整个领域驱动设计的难点。

领域事件：事件代表过去发生完成的事，它既是业务架构概念也是技术架构概念，以事件为驱动的编程技术模型称为事件驱动架构（EDA）。领域事件强调其业务概念。事件即指已经发生的事情，可以从动词完成时理解。

命令：命令表示事件的触发器。命令是请求，而事件是完成。命令相当于页面（UI）点击的按钮来触发一个需要完成的任务，这个完成的任务既是指一个事件。

命令命名和事件命名，命令命名相当于动词结尾的ing，事件命名相当于结尾的ed。

关键事件：即指识别状态机状态之间转换的事件，关键事件是领域边界划分的重要指标。

还有事件建模头脑风暴法，这个也是工作中会使用的方法，但是这种方法一定要确定会议各阶段目标，要不效率太低。

例如：首先，确定探索子域。

           2、确定探索有节上下文。

           3、确定用户角色，那些角色发出那些命令，完成那些事件。

           4、确定关键测试场景。

---

      可参考四色原型建模：

      1、moment-interval（某个时刻(moment)或一段很短时间(interval)内. 意味在某个时刻发生的事情因为业务要求或合法性原因需要跟踪；或者过一段时间以后，应该是很短的时间，可以帮助我们寻找到它。）

       卖东西是在某个时刻发生的，它有发生日期和时间。租赁行为是在一段时间内发生，从开始出租和归还所租物品；预定也是持续一段时间，什么时候预定；什么时候过期等。

　　这些我们都使用moment-interval原型来表达。Moment-intervals经常封装的是最关键的方法，为让其显目，moment-interval的UML图我们使用粉红颜色表示。如：订单，单据

      2、role（角色原型比较容易理解，任何一个系统都需要人或某个组织介入运行，例如论坛系统需要注册者角色发言；销售订单需要业务员角色制定，等等。）

       这里有一个Party原型定义：它表示一个可标识、可定位的单元，这个单元有自己正常的状态并且能够自主控制自己的一些行为，通常情况下，人或组织是一种Party，但象护照，身份证等注册性标志等都可以作为Party。

       Role角色是Party扮演的（a role that a Party plays），Party是角色Role的扮演者（role-player）。角色原型在UML中是使用黄颜色标识的。角色模型是第二重要的原型，所以使用黄色。如：订单的配送类型，用户的类别角色。

      3、description archetype

       比如你的红色福克斯是福特生产的一辆轿车，它有车牌号、购买日期、颜色和里程表等，这些代表Thing原型，那么作为轿车这个种类来说，它有一些种类属性，例如：生产厂家、生产批号、适用颜色等，这些属性是轿车这类所有车辆都共有的。

        在设计模式这个实现级别，我们通常使用组合模式来实现种类原型。Description原型在UML中使用蓝色表达。比如：客户实体的地址描述，这部分信息是可以通用的。

      4、party, place or thing

         party place或thing都可以成为角色原型，注意到角色原型中的UML图，party图是以绿色表达。比如：客户、商品。

电商DDD四色图示例