DDD峰会2020摘录
张逸 民航信息技术总监 《接构领域驱动设计》作者
领域驱动设计大揭秘
- DDD vs DDD （数据驱动 vs 领域驱动）
- DDD黑铁时代与黄金时代
- 单体架构是邪恶的吗
- DDD的不足与DDD-UP
传统与DDD
传统设计模型的分析
ER图，专注数据字段，到类设计层面就是数据表映射到数据类，这种类看作是一个携带数据的一种结构（数据实体）。也就是贫血模型（数据结构与算法分开，只有数据结构的模型）。
字段的重用。从超类的实现，到组合的实现。
贫血模型将算法聚集在一个没有状态的service里面，这个service称之为事务脚本，
上述的贫血模型+事务脚本的结合方式就是一种传统的面向过程的方式。
存在模块，服务，组件的概念
DDD下模型的重用
属性字段的重用，传统模型会通过超类实现，DDD从组合的角度实现。
限界上下文 - Bounded Context，是业务能力的纵向切分，顺应业务的变化方向
例：对于客户Customer模型而言，它在销售上下文与售后上下文中的关注点是不一样的
BC之间的重用，是借助业务能力进行重用的，而不是直接重用领域模型。
财务上下文中，关注往来账的业务能力。其中有运输费的业务，但是财务BC不具备计算运费的能力，运费领域模型包含了运输费，租赁费，人工费，保费等信息。这些是要在运输上下文中提供。对于财务BC，会提供一个结算账目的业务能力，它在结算的时候，需要得到一个运费，这就需要运输BC的业务能力。可以看到这里是通过业务能力（可能就是我们看到的一种RESTful服务）来保证重用的，而不是直接使用对方的领域模型，从而保证依赖降低（解耦）。
领域模型的知识语境。识别上下文，确定领域模型的知识语境
运输BC，需要商品的信息，但是只需要商品运输高度，运输深度，有没有回收，有没有收税这些属性。
商品BC中会定义一个商品类Product，运输BC中也会定义一个商品类Product，
先是业务层面，领域层面的纵向切分，再是技术角度来划分业务模块，数据访问模块。从编码的角度上看，如果业务发生变化，只影响到了其中一个类。
聚合与聚合根
对象的依赖，生命周期的管理。经常大量需要细粒度的类，这样会导致类关系图异常复杂。从对象的相关性进行划分边界进行聚合，然后为每一个聚合定义一个聚合根实体，聚合之间只允许聚合根之间进行关联，以此减少类与类的关系。
聚合根对外提供交互关系，内部的细节是它自己的实现，外部不需要关心。
限界上下文与聚合是DDD的核心模式。
黑铁时代与黄金时代
DDD是03年开始当时是一个很新的概念，对开发人员和设计人员来说，第一会导致知识上的增加。他们面临大量新概念新知识涌入的压力，其实是很难接受的。第二，他没有意识到限界上下的价值，BC是架构层次的自治单元。
南北向菱形模型：南向：领域-端口-适配器，北向：远程-本地-领域。 调用一般是南北走向？
随着微服务的诞生，DDD开始火起来。
微服务的协作就是限界上下文的协作。通过**Client防腐层？**调用上游微服务成为合理的选择。
单体架构与领域驱动架构风格
DDD的不足与补充
- 缺乏规范的过程指导，缺乏可操作性，团队实践过程中，更多取决于设计者的行业知识与设计经验，这就存在较大的偶然性。
- 没有匹配的需求管理体系。不同层次的业务需求贯穿于领域驱动设计过程中的每个环节，识别限界上下文和建立高质量的领域模型都有赖于良好的需求。需求管理体系直接影响领域驱动设计的质量。
- DDD的核心诉求是让业务架构和应用架构形成绑定关系，以面对需求变化时，使得应用架构能够适应业务架构的调整，满足架构的演进性。但是DDD却缺乏面向领域的架构体系，不足以支撑复杂软件项目的架构需求。
- 目前能和BC对应上的只有分层架构。后来还有六边形架构，还有上面所说的菱形架构
- DDD虽然以模型驱动设计为主线，却没有给出明确的领域建模方法。我们需要分别为领域分析建模，领域设计建模和领域实现建模提供对应的方法指导，减轻各个建模活动的知识负担，明确每个建模活动活动的领域模型的验证标准，避免领域建模的随意性。
- 分析模型，设计模型，实现模型应该保持一致。但是，没有提供方法告诉我们：怎么去提炼对象，怎么建立模型对象，模型从分析到设计到实现是怎么转换。
RUP? 问题空间-解空间
欧创新 《中台架构与实现：基于DDD和微服务》作者
当中台遇上DDD，如何设计微服务
顶层设计开始，行业领域不同关注也不同，阿里的通用能力中台关注公共业务领域，主要解决重复造轮子的问题。
战略与战术
DDD下的微服务边界
- 微服务单体内，基于聚合划分的逻辑边界，提供了微服务进一步划分的能力，这就解决了微服务内高内聚下面对变更时修改的难题。
- 限界上下文边界，在微服务落地的时候，就变成了微服务之间的物理边界。
于静 IBM资深应用架构师
领域驱动设计在大型遗留系统改造中的实践
制定目标与策略-业务梳理-微服务改造-集成测试迁移-反馈。这五个步骤循环往复。
- 业务梳理
- 用领域驱动的方式进行业务建模
- 抽象出一个业务模型，根据这个模型的关系划分限界上下文。 关键
- 有效深刻地理解现有的系统，梳理现有的业务。
- 系统改造最难的一点就是分析业务和代码：很难理解现有系统的一些业务逻辑，很难理解现有系统为什么这么设计，以及整个系统包含了哪些业务。
- 微服务改造
- 依据梳理出来的限界上下文，同时也需要先梳理现有系统架构，集成的方式，暴露的API，然后往微服务转换。
- 测试，生产迁移
- 环境，域名，数据
- 反馈
- 基于前几步骤，反馈给团队，以便更好地指导下一阶段的改造。
- 包含业务方反馈？
DDD引领微服务系统设计
如何识别系统边界？识别系统边界的一个实践就是事件风暴工作坊。
要求业务需求的提出者与技术实施者协作完成整个的领域设计建模（业务人员，开发，QA，PM等等，新实践需要教练主持人，通知准备，引导思路）
- 熟悉项目的成员介绍一下项目情况
- 专注背后的业务讨论
- 避免开发人员陷入系统设计中，要脱离数据库表设计的固化思维，跳出现有的代码设计。（主持人需要关注并提醒）
- 做好准备工作
- 专注业务讨论
- 可以邀请第三方接口团队人员参与
- 涉及三方接口时，可以邀请二方/三方团队参加
- 成果记录
- 推荐Mural
业务分析过程中，会出现一个疑问：遗留系统的业务逻辑一定都是正确、适用（新变更，新场景）的吗？
- 前后矛盾的逻辑
- 年久失修的逻辑
- 无人问津的逻辑
我们在设计领域模型的时候，需要考虑，或者顺带着纠正这些问题。
但是这些问题的解决取决于团队对系统的所有权（ownership）的强度（话事权高对改动是十分友好的。）
微服务实战
绞杀者模式：
通过逐步用新应用程序和服务，替换特定功能段，增量迁移旧系统。随着旧系统功能的更换，新系统最终取代了所有旧系统功能，扼杀并停用旧系统。
第一个功能段，先锋队，挑选一个规模较小，功能简单，业务较为独立的功能模块。
- 明确分层模型中各层的职责
- 脚手架工程（模板工程）
- 公共组件
- 防腐层
- 测试用例
- DevOps
- 云基础设施
士气：功能简单，时间周期战线不能拉太长。
规范：先锋队起试验作用，制定规范。
杨云 ThoughtWorks总监咨询师
DDD从战略实际到代码落地的三阶段方法
- 为什么大家觉得落地难
- DDD落地的三阶段方法
- 事件风暴来做战略建模
- 用名词动词法做子域内的结构化战术建模
- 用类型流做行为内部的微观详细设计
模型：软件的核心骨架，核心约束，核心概念的一个可视化体现。
百人团队的DDD模型落地，具体到直观的微观模型，保证模型和代码的一致性。
歪：个人重构感悟
术语对齐。事件风暴，业务梳理，设计与落地的走样的问题