实战化领域驱动设计工作坊
2020-02-23 123浏览
- 1. 全球软件咨询公司 实战化领域驱动设计工作坊 概念讲解 (DDD China 2019 Conference) © ThoughtWorks 2019 1
- 2. 讲师团队 © ThoughtWorks 2019 胡皓 王岩 钟健鑫 朱海波 王瑞鹏 林宁 2
- 3. 为何需要领域驱动设计？ © ThoughtWorks 2019 3
- 4. 现实世界的挑战 © ThoughtWorks 2019 4
- 5. 难以理解的代码 编程中最难的事情之一就是命名 © ThoughtWorks 2019 5
- 6. 混乱不堪的模型 拍脑袋建模 © ThoughtWorks 2019 6
- 7. 发散式变化 & 散弹式修改 依据变化的边界进行架构和编程——最简单也最困难 业务A 业务B 业务 业务C 模块 业务D 模块 模块 © ThoughtWorks 2019 模块 模块 模块 7
- 8. 大泥球架构 技术与业务不能匹配的最终结果 © ThoughtWorks 2019 8
- 9. 微服务压垮了最后一根稻草 从大泥球到分布式泥坑 © ThoughtWorks 2019 https://maveric-systems.com/blog/microservices-i-microservices-vs-soa 9
- 10. 领域驱动设计的诞生 © ThoughtWorks 2019 10
- 11. 领域驱动设计 从低调沉稳到日渐火爆 领域驱动 设计 持续完善 影响力持续增加 Eric Evans 2003 实现领域 驱动设计 … … Vaughn Vernon Martin Fowler James Lewis 2013 2014 事件风暴 Alberto Brandolini © ThoughtWorks 2019 微服务 架构 领域驱动设 计：模式、 原理与实践 领域驱动 设计精粹 Scott Millet Nick Tune Vaughn Vernon 2015 2016 微服务带来的架构复杂度成倍提升，引爆 了“技术和经验驱动设计”的顽疾。 数字化时代快速变化的典型特征，进一步 敲响了低响应力架构的丧钟。 11
- 12. 领域驱动设计解决问题的方式 © ThoughtWorks 2019 12
- 13. 分解大泥球 以子域、限界上下文为参考，通过聚合的方式进行建模 © ThoughtWorks 2019 https://p2p.wrox.com/book-patterns-principles-practices-domain-driven-design-789/ 13
- 14. DDD与传统设计方法的对比 需求文档 角色间相互推诿 技术实施细节 经验建模 混乱的词汇 面向技术进行架构 难以理解的代码 面向业务进行架构 代码即文档 大泥球架构 协同设计 各角色通力协作 聚焦业务问题 领域建模 统一语言 松耦合架构 © ThoughtWorks 2019 14
- 15. 聚合根 DDD是更有套路的设计方式 实体 值对象 领域服务 领域事件 业务抽象 决策命令 基于抽象业务 的参考 领域模型 工厂 仓库 领域名词 API设计 协作设计 统一语言 限界上下文 基于概念边界 的参考 上下文依赖关系 分层架构 核心域 问题域划分 支撑域 通用域 服务/模块/包拆分 基于投资优先级 的参考 资源分配策略 开发/集成策略 技术栈选择 团队分组/分工 © ThoughtWorks 2019 15
- 16. 核心原则 面向业务进行架构 © ThoughtWorks 2019 聚焦核心域 协作设计 统一语言 澄清问题域，聚焦核心 竞争力，优化资源投入 领域专家同软件专家通 过创造性协作，迭代式 的探索和发现模型 利用明确且有边界的业 务上下文统一语言 16
- 17. DDD在产品研发过程中的位置 Design Thinking + Domain Driven Design + DevOps © ThoughtWorks 2019 17
- 18. 如何开展领域驱动设计？ © ThoughtWorks 2019 18
- 19. 分段式协作设计 © ThoughtWorks 2019 19
- 20. 统一语言 分段式协作设计 三个阶段 从问题出发，逐级抽象，层层深入和细化 ● 战略设计 ● 战术设计 战略设计 战术设计 技术实现 澄清业务与问题 建立抽象模型 深入实现细节 ● 技术实现 © ThoughtWorks 2019 20
- 21. 分段式协作设计 战略设计阶段 多说问题，少说方案 业务梳理和抽象 限界上下文识别 子域识别 © ThoughtWorks 2019 21
- 22. 分段式协作设计 战术设计阶段 持续抽象，忽略技术细节 领域建模 业务服务识别 业务服务API能力识别 © ThoughtWorks 2019 22
- 23. 分段式协作设计 技术实现阶段 一切皆是细节 API详细设计 UML设计 数据库设计 部署与运维 …… © ThoughtWorks 2019 23
- 24. 如何实现领域驱动设计？ © ThoughtWorks 2019 24
- 25. 松耦合架构 © ThoughtWorks 2019 25
- 26. 微服务设计 以业务边界为参考，实现架构与业务对齐 © ThoughtWorks 2019 https://maveric-systems.com/blog/microservices-i-microservices-vs-soa 26
- 27. 分层架构设计 以领域为核心，以变化的原因和聚合为边界，提供分层守护 https://maveric-systems.com/blog/microservices-i-microservices-vs-soa © ThoughtWorks 2019 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 27
- 28. 代码实现样例 Talk is cheep, show me the code. https://github.com/howiehu/ddd-architecture-samples © ThoughtWorks 2019 28
- 29. 工作坊开始 通过假想的业务实际操作和体验领域驱动设计 © ThoughtWorks 2019 29
- 30. 一个简单粗暴的需求 嘿！我是你们的老板！我很有钱！我需要做一个产品干掉市场上那些 倒霉的外卖产品！ 30
- 31. 电梯演讲 (Elevator Pitch) ● 使用便利贴在白纸上贴出电梯演讲的结构。 ● 每个人为电梯演讲的每一行想象一个内容，通过 ● 便利贴的方式进行书写（每个人应该写出7个便 WHO [ statement of the need or opportunity ] 利贴）。 THE [ product name ] 每个人将自己的7个便利贴放在白纸上相应的位 置，共同阅读并讨论以形成共同意见，让电梯演 讲看上去更有吸引力，更可行且更通顺，必要的 时候可以采取投票等方式达成一致（这只是一个 练习，所以大家开心优于纠结😄😄）。 ● FOR [ target customer ] 利用便利贴修改并调整电梯演讲到最终结果，然 后每组将自己的电梯演讲分享给大家。 IS A [ product category ] THAT [ key benefit, compelling reason to use ] UN LIKE [ primary competitive alternative ] OUR PRODUCT [ statement of primary differentiation ]. 31
- 32. 数字化架构能力小组 咨询 BU dac@thoughtworks.com | thoughtworks.com © ThoughtWorks 2019 32
