2019年领域驱动设计中国峰会：DDD和功能解耦.pdf

《2019年领域驱动设计中国峰会：DDD和功能解耦.pdf》由会员分享，可在线阅读，更多相关《2019年领域驱动设计中国峰会：DDD和功能解耦.pdf（31页珍藏版）》请在三个皮匠报告上搜索。

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 Cou