领域驱动设计剖析.ppt

什么是CQRS？ CQRS是Command Query Responsibility Segregation的简拼。 CQRS建议将修改系统状态的模型和读取系统状态的模型给分开进行开发。 CQRS经典架构 CQRS容易产生的误解 CQRS必须采用EventSource吗？（否） CQRS必须采用In Memory吗？（否） CQRS必须采用DDD吗？（否） CQRS必须采用Command模式吗？（否） CQRS必须采用两个（读写）数据库吗？（否） FAQ 鸣谢 汤雪华： /netfocus。 陈晴阳：/daxnet。 为什么值对象是不可变的？ 百度一下为什么原子类型是不可变的。 列表做为值对象 列表必须做为一个整体拥有值对象的语义。如：String是Char的列表，String是值语义（Java和C#等多数语言是如此，Ruby中则不然）。 值语义的实体 因为值语义能带来一定的安全性，某些实体为了拥抱这个优点就使用值语义。 实体间的关系 万物皆有关系。 关系越多，耦合越大。 找出整个业务生命周期都依赖的关系，某些关系或许只在对象创建时刻有意义。 可以用标识间接表示关系。 尽可能的简化关系。 尽可能的避免双向关系。 聚合 聚合是一簇相关联的对象，出于封装的目的，将这些对象作为一个单元（业务、持久化和并发）。 每个聚合都有一个边界和一个根。 边界定义了聚合中应该包含什么。 根是聚合中唯一允许被外部引用的元素，在聚合边界内，对象之间可以相互引用。 聚合根使用全局标识，由仓储负责其持久化相关的生命周期，实体使用局部标识，由聚合根负责其持久化生命周期。 工作流-概念模型 工作流-流程定义聚合 工作流-流程实例聚合 聚合的一致性 聚合内的一致性由聚合自身负责维护。 跨聚合的一致性由服务负责维护。 这里不会谈“最终一致性”。 一致性的最高目标是啥？ 应用层随意的使用领域模型，不会导致模型处于非法的状态（反射除外）。 订单的一致性 订单的一致性 OrderItem的Subtotal = OrderItem的Quantity * OrderItem的Price。 Order的Total = Order的所有OrderItem的Subtotal之和。 Order的OrderCode必须唯一，编码规则最好能方便自定义。 XXX其它信息验证规则。 如何保证聚合内的一致性？ 对聚合内的任何修改都要经过聚合根，聚合根负责一致性检查。 聚合内除了聚合根之外的实体只能被临使用。 值对象因为拥有了值语义，天生安全。 订单-封装集合 订单-状态模式 如何保证跨聚合的一致性？ 马上会讲到服务 聚合的生命周期 开始 透明 Factory.Create() Repository.Add() 持久化 Repository.Load() 未变化 this.Change() 已修改 Repository.Update() 订单-工厂 信息专家模式 如果将职责分配给某个类型，则这个类型必须拥有完成职责所需的信息。 工厂封装了领域模型的创建职责。 仓储封装了聚合的持久化职责。 实体和聚合根封装了保证自身一致性的职责。 服务的职责是什么？ 服务 服务封装了保证跨聚合一致性的职责。 会不会有胖服务呢？ 转账服务示例 使用DCI替换服务 什么是DCI？ Context 选择 Data，让 Data ?扮演 Role 执行 Interaction。 技术上如何扮演Role？ 开发期注入 Mixin Trait Template 运行期间注入 Mixin DynamicProxy Wrapper 转账场景示例 使用Domain Event替换服务 VS 最终一致性和异步事件 .NET：/tangxuehua/enode。 Java：/jdonframework/。 使用四色原型划分聚合 四色原型找到这样一个规律：某个团体（Party）的某个角色（PartyRole）在某个地点（Place）的某个角色（PlaceRole）用某个东西（Thing）的某个角色（ThingRole）做了某件事情（MomentInterval）。 和DCI有点关系吧？ 四色原型 四色原型 PartyPlaceThing （PPT）：用淡绿色表示，常见的PPT有：部门、岗位、人员、地点、物品等。 Description（Des）：用淡蓝色表示，主要用来对PPT进行描述，常见的Des有：部门类型、岗位层级、人员类型、地点区域、物品分类等。 Role：用淡黄色表示，主要表示PPT在某个场景下扮演的角色，常见的角色有：请假申请者、计划参与者等。 MomentInterval（MI）：简称MI，用淡红色表示，主要表示在一刻或一段时间内发生的一件事情，常见的MI有：部门移动、岗位移动、员工离职、