领域驱动设计

领域驱动设计应对复杂性之道广告目录O什么是领域驱动设计？O为什么使用领域驱动设计？O和其它设计方法的比较。O什么是领域模型？OFAQ。什么是领域驱动设计？O英文名字：DomainDrivenDesign。O缩写：DDD。O概述：DDD是一种以领域为核心的设计和开发理念。DDD通过维护一个深度反应领域概念的模型，以及提供了可行的经过实践检验的大量模式来应对领域的复杂性。流程领域用例1用例2用例n模型规则参与参与问题空间驱动领域设计映射（聚合模式）方程映射（仓储模式）映射（其他模式）设计解空间聚合仓储其他类型跨越鸿沟用户视图开发视图概念模型用例规约领域模型应用服务DDD为什么使用领域驱动设计？为了应对快速变化为了应对复杂性为什么能应对复杂性？系统模块聚合分而治之模块应用层领域层技术维度业务维度时间维度迭代迭代注意O复杂性来源于业务本身，DDD帮我们合理的应对复杂性，而非降低复杂性。为什么能应对快速变化？概念模型直接的映射领域模型更高层次的编程注意O变化是必然，随着时间的流逝，领域会发生变化，我们对领域的认识也会发生变化，要做的只有拥抱变化。心态决定一切和其它设计方法的比较领域50米数据库驱动面向对象分析和设计100米领域驱动1米痛苦指数只缘身在此山中O如果您已经使用领域的概念进行编程（OO、OP、FP和SQL等），那么恭喜您！您已经掌握了“领域驱动设计”的核心了。客户导向如何接近领域进行编程？将概念显式化统一语言中文编程？什么是领域模型？界限上下文聚合实体值对象服务清晰的边界没人喜欢蜘蛛网。订单的领域模型领域模型在架构中的位置架构示例SPI领域模型及相关概念领域模型O实体有业务生命周期，使用标识进行跟踪。O值对象无业务生命周期，用来描述实体。O服务无状态的行为类型，表示某种能力。现实世界实体软件世界EmployeeLeaveApplication需要被跟踪是重点名词都是实体吗？只有需要被跟踪的名词才是实体。值对象哪一张都行！容易混淆的值对象基础资料管理政治面貌人力资源管理员工政治面貌为什么值对象是不可变的？百度一下为什么原子类型是不可变的。列表做为值对象O列表必须做为一个整体拥有值对象的语义。如：String是Char的列表，String是值语义（Java和C#等多数语言是如此，Ruby中则不然）。值语义的实体O因为值语义能带来一定的安全性，某些实体为了拥抱这个优点就使用值语义。实体间的关系O万物皆有关系。O关系越多，耦合越大。O找出整个业务生命周期都依赖的关系，某些关系或许只在对象创建时刻有意义。O可以用标识间接表示关系。O尽可能的简化关系。O尽可能的避免双向关系。聚合O聚合是一簇相关联的对象，出于封装的目的，将这些对象作为一个单元（业务、持久化和并发）。O每个聚合都有一个边界和一个根。O边界定义了聚合中应该包含什么。O根是聚合中唯一允许被外部引用的元素，在聚合边界内，对象之间可以相互引用。O聚合根使用全局标识，由仓储负责其持久化相关的生命周期，实体使用局部标识，由聚合根负责其持久化生命周期。工作流-概念模型工作流-流程定义聚合工作流-流程实例聚合聚合的一致性O聚合内的一致性由聚合自身负责维护。O跨聚合的一致性由服务负责维护。O这里不会谈“最终一致性”。一致性的最高目标是啥？O应用层随意的使用领域模型，不会导致模型处于非法的状态（反射除外）。订单的一致性订单的一致性OOrderItem的Subtotal=OrderItem的Quantity*OrderItem的Price。OOrder的Total=Order的所有OrderItem的Subtotal之和。OOrder的OrderCode必须唯一，编码规则最好能方便自定义。OXXX其它信息验证规则。如何保证聚合内的一致性？O对聚合内的任何修改都要经过聚合根，聚合根负责一致性检查。O聚合内除了聚合根之外的实体只能被临使用。O值对象因为拥有了值语义，天生安全。订单-封装集合订单-状态模式如何保证跨聚合的一致性？马上会讲到服务聚合的生命周期开始透明Factory.Create()Repository.Add()持久化Repository.Load()未变化已修改订单-工厂信息专家模式O如果将职责分配给某个类型，则这个类型必须拥有完成职责所需的信息。工厂封装了领域模型的创建职责。仓储封装了聚合的持久化职责。实体和聚合根封装了保证自身一致性的职责。服务的职责是什么？服务O服务封装了保证跨聚合一致性的职责。会不会有胖服务呢？转账服务示例使用DCI替换服务什么是DCI？OContext选择Data，让Data扮演Role执行Interaction。技术上如何扮演Role？O开发期注入OMixinOTraitOTemplateO运行期间注入OMixinODynamicProxyOWrapper转账场景示例使用DomainEvent替换服务VS最终一致性和异步事件O.NET：。OJava：。使用四色原型划分聚合O四色原型找到这样一个规律：某个团体（Party）的某个角色（PartyRole）在某个地点（Place）的某个角色（PlaceRole）用某个东西（Thing）的某个角色（ThingRole）做了某件事情（MomentInterval）。和DCI有点关系吧？四色原型四色原型OPartyPlaceThing（PPT）：用淡绿色表示，常见的PPT有：部门、岗位、人员、地点、物品等。ODescription（Des）：用淡蓝色表示，主要用来对PPT进行描述，常见的Des有：部门类型、岗位层级、人员类型、地点区域、物品分类等。ORole：用淡黄色表示，主要表示PPT在某个场景下扮演的角色，常见的角色有：请假申请者、计划参与者等。OMomentInterval（MI）：简称MI，用淡红色表示，主要表示在一刻或一段时间内发生的一件事情，常见的MI有：部门移动、岗位移动、员工离职、销售出库等。如何划分聚合？OPPT和MI毫无疑问是独立的聚合，MI可能有MIDetail，MIDetail包含在MI所在的聚合，MI是聚合根。ODes要根据其是否需要被跟踪来具体对待，如果需要被跟踪就是独立的聚合根，否则是值对象。ORole和DCI的Role应该一样，是一种组织代码的思路。使用CQRS进一步分离职责什么是CQRS？OCQRS是CommandQueryResponsibilitySegregation的简拼。OCQRS建议将修改系统状态的模型和读取系统状态的模型给分开进行开发。CQRS经典架构CQRS容易产生的误解OCQRS必须采用EventSource吗？（否）OCQRS必须采用InMemory吗？（否）OCQRS必须采用DDD吗？（否）OCQRS必须采用Command模式吗？（否）OCQRS必须采用两个（读写）数据库吗？（否）FAQ鸣谢O汤雪华：。O陈晴阳：。