1、DDD和功能解耦1.2.3.4.5.为什么选择DDDDDD和系统解耦DDD和统一语言总结我们为什么选择DDDY轴扩展性成为瓶颈低内聚高耦合领域模型不合理影响Y轴扩展的两个因素这意味着Y轴的扩展要灵活我们为什么选择DDD问题一：领域模型不合理错误的数据结构错误的业务约束缺乏业务语义的模型没有发现隐式的概念产品经理关注上层的业务流程和交互程序员关注技术实现我们为什么选择DDD问题二：系统功能间的各种耦合ABA的数据AB全局数据Content CouplingCommon CouplingABB不需要Stamp CouplingB需要ABData CouplingB需要数据格式由B来定义耦合的类型但

2、是DDD落地很难让整个团队弄清楚复杂而抽象的方法论，太难了那怎么办？简化，小步，例子多而是面向对象分析和设计最先要普及的不是DDD|二十多年前人们就推崇用值对象了|那时DDD还没有诞生Primitive Obsession|基本类型偏执|2000年这种坏味道是指用基本类型来表示领域概念，比如用字符型来表示电话号码、邮政编码等解决办法是定义明确ValueObject。https:/riehle.org/computer-science/research/1998/ubilab-tr-1998-10-1.html丰富的表达力降低认知负担提升可读性集中的合集中的合法性校验法性校验和易测试和易测试性性

3、比如电话号码的比如电话号码的校验校验不可变性带来的线程安全封装带来封装带来的设计柔的设计柔性性后面会有实际的后面会有实际的例子例子|Since|1997年|实体和聚合早就被广泛认可了富血模型贫血模型|很多原则和模式在系统级别依旧有效设计原则依赖倒置开放封闭单一职责信息隐藏设计模式工厂适配器策略状态架构模式分层架构整洁架构/洋葱模型端口适配器架构CQRS|面向对象富血模型没落史|1980s，Smalltalk/C+带领下面向对象广泛流行|1991，Visual Basic 出现属性和属性列表功能|1992-1995，可视化工具和IDE遍地开花|1996，JDK1.0发布|1997，JavaBea

4、n规范发布|1998-，Java和.NET平台出现大量的通过反射|机制处理对象属性的工具和框架FROM实现领域驱动设计|背后的驱动力专业的单机软件向以数据为中心的网络软件的演变理论上，使用DDD并不一定要通过面向对象，但实战中，使用面向对象进行分析设计是最务实的。那么，DDD在面向对象之外还带来了哪些新的东西？首先要理解的是限界上下文该了解些DDD最核心的概念了|案例分析1：概念不能穿透上下文123除了更好的表意性外有更好的扩展性|案例分析1：变化控制在局部APIController数据库领域层业务逻辑代码不用变企业客户适配器企业客户适配器用户适配器API适配器u 只有适配器部分的代码需要变化

5、，包含业务逻辑的领域层代码不需要变化u通过编译器的静态类型检查，适配器的变化点很容易识别u适配器充当防腐层（ACL），起到了概念隔离和功能解耦的作用RPCRPC|案例分析2：上下文关系和Common Coupling订单订单生产控制中心WMS餐饮TMS购物卡读取订单上的标记读取订单上的标记读取订单上的标记读取订单上的标记交易服务按各系统的需要生产订单时在订单上打标记“订单标记委员会”分布式大泥团系统的守护神标记太多位，含义二义性，新增需求改动的系统太多，影响范围难以界定，沟通成本非常高|案例分析2：上下文关系和Common Coupling订单订单生产控制中心WMS餐饮TMS购物卡交易服务UD

6、UUUUUUDDDD自己领域的守护神自己领域的守护神自己领域的守护神自己领域的守护神自己领域的守护神清晰的上下文映射关系，下游理解上游的领域概念，上游不理解下游的领域概念，上游制定标准，下游适配标准。*在DDD的上下文映射中，我们优先使用这种“客户-供应商”的模式。D，下游；U，上游|案例分析2：进一步要避免的问题WMSTMSUDWMS产品研发TMS产品研发WMSTMSUDWMS产品研发TMS产品研发下游要保持独立性，需要使用适配器/防腐层TMS不需要TMS需要数据上游“老好人”，边界没守住，造成Stamp Coupling|案例分析1&2：系统间的依赖倒置/ACL保证Data Couplin

7、g数据库领域层业务逻辑用户适配器RPCAPIController领域层业务逻辑API适配器（D）下游（U）上游下游定义的接口适配上下游接口的实现|案例分析3：上下文级贫血和Control Coupling订单生产控制中心订单订单生产控制中心订单外部调用或消息1.获取订单数据做逻辑判断2.设置订单状态3.操作其它系统外部调用或消息1.给订单状态机输入可枚举的事件2.监听得到订单状态的变化3.操作其它系统|案例分析4：聚合根的作用聚合根是一组实体和值对象的一致性边界。在这个边界之内维护不变条件，即业务规则。这不是DDD引入的新原则，聚合就该如此。DDD的新原则包括：n 通过唯一标识引用其他聚合n

8、在边界之外使用最终一致性（比如通过领域事件），一个事务只能修改一个聚合聚合的识别很难，领域事件、领域服务和CQRS的正确应用可以减少技术因素对聚合根识别的干扰。这样做的好处是能更好地支持架构的演进其次要理解的是统一语言该了解些DDD最核心的一些概念了|领域太复杂，只有在分割的上下文内|才可能形成统一的语言|物理世界在不同上下文代表着|不同的概念店仓厨房拣货打包车间让开发者做回正常人控制节奏，慢下来很难但很重要学会问问题，挖掘隐形概念命名很难，那就随便给个名字先达成一致统一语言的形成|使用事件风暴形成统一语言隐形概念的挖掘，聚合根的识别等都非常难且难以达成一致，仅仅在方法论上达成一致还不够，我们

9、需要一种容易执行的工具|代码和分析模型的低表示差异聚合根值对象领域事件普通实体Repository接口Repository实现应用服务业务模型和业务逻辑都在这里业务模型和业务逻辑都在这里应用服务应该很“薄”和技术相关的实现|没有一个完美的ORM可以用JPA/Spring-Data-JDBC 富血，但性能不可控JDBC/MyBatis 性能可控，贫血RoR/Domain注入Repo(AspectJ)，貌似解决以上问题，但污染领域模型|用JPA来实现，好处/坏处：富血模型 聚合根的原则 但带来了糟糕的或不可控的性能|权衡应用层的方法聚合根助手的方法聚合根的方法应用层尽可能薄，不包含领域层的业务逻辑每个聚合根配一个无状态的助手，和聚合根一起体现所有的领域业务逻辑如果开始分不清代码放在哪一层，可以先实现然后通过重构渐进下沉界定上下文并明确其间的关系挖掘领域知识，识别隐型概念，定义聚合根,形成团队理解一致的统一语言让代码尽可能和分析模型保持一致未必能尽善尽美，但可以不断趋近THANKS