[Image](/uploads/documents/6/a/b/4/6ab4247745e32a8af9b45925f095fdae/p3_1.jpg) ## 内容大纲 • 战略的坑 - 分析的坑 - 限界上下文的坑 • 聚合的坑 • 仓储的坑 ## 战略的坑 ## 无差别地全面采用DDD战术建模 核心域 通用域 支撑域 • DDD战术建模适用于重要或复杂的业务，初期投入成本较高； - .jpg) 模型需要迭代演化 ## 限界上下文的坑 ## 可能导致上下文耦合的共享模型  支付 耦合了不同行为的客户 分解客户在不同BC的行为 应用四色原型分解客户行为 上下文中模型概念一致还不够，还要保持内涵（行为和职责）一致 和职责）一致 ## 藕断丝连的限界上下文边界 存储上的藕断丝连 遗留系统上下文（可被替换） A上下文 通过防腐层隔离 B上下文 上下文A 上下文B 上下文A 上下文B 上下文A 上下文B ↓ BC划分物理边界的意义在于Inter-Operate，而不是Integrate；Inter-Operate是指定义系统边界和接口，并为整个团队提供完整的堆栈，实现完全的自制。如此就能降低系统间的依赖性，减少通信成本；

d4f40b277dfbb64/p21_1.jpg) ## 划分限界上下文 √限界上下文明确地定义模型所应用的上下文。 ✓根据团队的组织、软件系统的各个部分的用法以及物理表现(代码和数据库模式等)来设置模型的边界。 ✓在这些边界中严格保持模型的一致性，而不要受到边界之外问题的干扰和混淆。 ✓子域对应的是问题空间，限界上下文对应的是解决方方案空间。  ## 限界上下文的业务边界  动态的业务流程按照业务边界切分出来的静态业务单元 ## 限界上下文的工作边界  逻辑边界  物理边界 ## 限界上下文的识别过程

## RUP 4+1 视图与DDD的关系 |RUP 4+1视图|领域驱动设计的模式与实践| |---|---| |场景视图|领域场景分析、用例图| |逻辑视图|限界上下文、上下文映射、分层架构| |进程视图|限界上下文、六边形架构、上下文映射| |物理视图|六边形架构| |开发视图|分层架构、代码模型| ## 场景视图  系统层面  ## 限界上下文层面  ## THANK YOU

jpg) ## 限界上下文拆分 CAD翻模上下文 建模子域 模型编辑上下文 截面钢筋模型上下文 做法子域 平法模型上下文 做法上下文 三维模型转换 上下文 构件模型上下文 模型检查上下文 • 业务用例 • 功能\语义相关性 • 技术应用 ## 计算子域 通用子域 团队规模 土建计算设置上下文 钢筋计算设置上下文 登录与授权上下文 指标管理上下文 指标子域 指标定制上下文 ## 限界上下文协作关系  ## 计算子域 - 识别真实依赖关系 - 确定上下文物理边界 - 业务演化的趋势 ## 限界上下文解耦-统一接口设计 ## Facade模式 模型检查 上下文 CAD翻模上下文 CAD翻模上下文 统一接口 截面钢筋模型上下文 钢筋计算上下文 解决： 接口不规范，多套接口 外部接口深入到上游的业务逻辑 ## 限界上下文解耦-发布订阅机制 发布-订阅机制 建模模型上下文 发布 调度中心 解决： 上游模型变化，下游模型联动 钢筋模型 上下文 平法模型上下文 ## 架构演进 领域拆分 架构分层 构建领域模型 ## 架构分层 模型转换 显示层

业务数据的变化。  ## 划分限界上下文 ## 如何进行事件风暴？ 1. 确定要进行事件风暴的业务场景，场景需要单一而且清晰； 2. 用“XXX已XXX”的格式在橙色便利贴上写下事件，工作坊参与者需要对事件定义达成一致； 3. 根据时间顺序把事件便利贴贴到白板上； 例1: 提交客户订单  ## 划分限界上下文 ## 为什么用命令? 事件是业务上的输出，命令是业务上的输入。命令以及相应角色可以明确最终软件系统会有哪些功能给外界使用。命令和事件将会在后续的环节中指导API的设计。 ## 如何进行命令风暴？ ## 寻找聚合  ## 划分限界上下文 ## 如何寻找聚合? 1. 按照事件顺序依次通过提问来分析： - 这个事件会改变的领域模型是什么？明确领域模型（简单理解就是事件中的涉及的业务名词） - 这个领域模型是否可以独立访问？如果是就是聚合

- 初步划分限界上下文  识别子域  2 初步划分限界上下文  如何进一步划分限界上下文？ ## DDCHINA ## 架构演进 - 阶段1 - 进一步划分限界上下文 ## 限界上下文划分依据 ![Image](/uploads/documents/c/2/0/0/c2001aae5d4cf743c242b5f9366c47d1/p21_1 • 围绕团队创建上下文 一个限界上下文有一个特性团队负责：2PTS from Millett S., Tune N. - Patterns, Principles, and Practices of Domain-Driven Design ## • 业务边界 识别业务主题：利用语义相关性和功能相关性对用例归类单一抽象层次原则+正交原则 ## • 工作边界 避免限界上下文工作边界过大：2PTS

领域驱动设计是微服务系统架构的最佳指南  微服务：限界上下文 ## 聚合与数据一致性 RULE: MODEL TRUE INVARIANTS IN CONSISTENCY BOUNDARIES • A properly designed Aggregate [Image](/uploads/documents/3/9/9/9/399948be56bf3010796e74b18b58fbb9/p27_1.jpg) ## 一 致性方案选择建议 • 微服务：限界上下文 • 聚合边界：强一致边界 • 限界上下文 -> 1 .. N 聚合 • 内刚 微服务内：聚合通过数据库事务保证强一致 • 外柔 微服务间：最终一致 如果需要分布式强一致，先考虑设计是否合理而非追求最新

Domain • Supporting Domain • Generic Domain ## Bounded Contexts - 业务上下文 - 定义领域模型的应用范围和其上下文 Context Mapping - 上下文映射 • 负责不同上下文之间的协作 • Shared Kernel • Anti-Corruption Layer ## Tactical-战术建模 Entity e6f/p19_1.jpg) Effective: 可以让实践者在数小时内理解复杂业务模型 Engaging: 带着问题的和拥有答案的人一起来构建模型 Efficient: 能快速发现界限上下文以及相关的聚合根等  Alberto [Image](/uploads/documents/4/0/7/5/40750bf1f86244e6930c200f69cabe6f/p20_5.jpg) 寻找聚合 通过什么产生？ 划分子域&界限上下文  分解系统（划分微服务） ##

p11_1.jpg) ## 电商系统 退换货 推荐 支付 客服 订单 用户 促销 会员 物流 商品 库存 商户 ## 如何做战略设计？ 高大上 VS 朴素 ## 限界上下文的形态 进程 软件包（jar） 命名空间 ## 理想的战术设施 应用服务 企业对外服务 聚合根 算法 核心业务 资源库 数据 IT资产 ## 无法避免的贫血模型 ![Ima

22_2.jpg)  DDD限界上下文 ## 4 步搞定微服务的划分 Analyze domain Define bounded contexts Define entities, aggregates, and services