基于 DDD 思想的酒店整体架构战略调整

1. 基于DDD思想的酒店整体架构战略调整郑吉敏去哪儿旅行技术总监

2.

3. • 自我介绍 • 工作13年，2次创业经历（2010~2013，2016~2018） • 2019.8入职，技术总监、技术委员会委员、业务架构SIG负责人 • 技术中心/酒店研发/酒店报价中心TL、业务架构组TL • 2020年度金项奖评选，主导的【对内DDD对外API驱动的酒店报价业务重塑】项目获 CEO特别奖、优秀技术贡献奖 • 2021年度金项奖评选，主导的【大主站+微服务技术架构战略落地】项目获三等奖 • 2021年度技术品牌最佳贡献奖，曾在多个业界大会做过技术分享

4. • 背景与现状 • 基于DDD思想的规划 • 落地步骤 • 思考与总结

5. • 背景介绍机票目的地事业群成立 •组织架构大调整统一服务、用户体验团队等 •业务架构大调整机酒交叉等战略方向调整 •系统架构如何演进？

6. • 问题及表现   产品吐槽  每个需求要和多个技术团队沟通，合作麻烦  经常需要升级，才能达成共识引申问题  看着简单的需求，链路很长，总有团队工时是因为要透传  技术方案不同团队意见不一，边界不够清晰

7. • 问题分析一 • 各个流程都涉及的团队是报价团队，报价团队是后端团队 • 用户端跨页面交互统一需要在底层的报价团队完成 • 底层修改，会带动整个链路跟着修改（比如基础数据） • 报价团队自己定位是给出酒店房型、价格及实际的优惠细节

8. • 问题分析二 • 很多团队在自己的领域层上面都有应用层 • 这些应用层，导致有些事情上下游团队都可以做 • 很多事情，都能做的时候可能出现都不想做 • “万金油”式架构，适合业务上升期，不适合稳定期

9. • 背景与现状 • 基于DDD思想的规划 • 落地步骤 • 思考与总结

10. • Qunar遇上DDD 机票辅营【商品】DDD 门票玩乐DDD-方舟计划 2020.4 2020.6 2020.5 2020.8 2020.7 2020.10 2020.9 旅行交通【资金流】DDD 酒店报价DDD • 方向覆盖 • 成果及推广  微服务架构优化型DDD实战  酒店报价DDD项目获“CEO特别奖”  自上而下中台搭建型DDD实战  “DDD领域驱动设计”技术系列课分享  自下而上业务重塑型DDD实战  业务研发内部多个项目进行DDD落地

11. • 基于Explicit • Architecture分析从外向内，越向内越偏核心原则，核心原则应该稳定不变 • 外层基于核心原则适配不同的业务场景，组装内层的能力 • 内层不依赖外层，即不受业务变化而变化 • 边界明显，尤其是领域层与应用层之间 • CQRS机制，耦合度低

12. • 整体架构构想

13. • 战略调整规划  •  • 战略调整核心突出核心领域，落地大前台相比之前区别领域层聚焦可复用能力，专注策略、玩法的改进 • 应用层聚焦业务识别与扩展，组装下游能力 • 业务收敛到一个团队，这个团队了解下游可提供的能力

14. • 优势劣势分析   优势（偏向中台方向）  很多需求，产品只需要对接前台一个团队即可  主流程链路变短，出问题定位及解决更容易劣势及可能带来的问题  短期内，已有的工作习惯发生变化  可能带来上游团队人员不稳定

15. • 背景与现状 • 基于DDD思想的规划 • 落地步骤 • 思考与总结

16. • 落地步骤 •应用归属团队调整系统架构 •已有逻辑调整归属调整组织架构调整 •数据回传技术方案标准化标准制定 •请求处理标准化 •组织架构按需调整 •核心人员归属团队规划 •HC调整，招聘计划跟进 •成立业务架构组

17. • 技术方案标准一：数据回传标准化 SPU维度（商家、酒店等信息） SKU维度（酒店房型及价格优惠）

18. • 技术方案标准二：请求处理标准化-方案制定节日来临，业务侧希望放开某些商促限制，给所有用户使用商促：用户画像打包，满足特定要求（比如特定的用户身份）的营销活动，拿到更低的底价，获得更高的利润

19. • 技术方案标准二：请求处理标准化-方案制定 • 前台修改用户身份，其他团队不感知  用户身份变了，其他链路是否受影响？ • 报价团队识别场景，做特殊商促匹配  报价正常提供能力，现在要提供定制化功能？ • 标准做法，缺少对【场景】的应对

20. • 技术方案标准二：请求处理标准化-方案制定酒店新客身份 userid、特征有限个场景 when、who、how、高星首单机酒用户 where、what 及组合异地面纱门店新客常住地为北京的用户有机酒交叉券的用户

21. • 技术方案标准二：请求处理标准化-方案制定 • 前台修改用户身份，其他团队不感知  用户身份变了，其他链路是否受影响？ • 报价团队识别场景，做特殊商促匹配  报价正常提供能力，现在要提供定制化功能？  报价提供“强制使用指定商促能力” 前台识别场景，组装使用新能力

22. • 技术方案标准二：请求处理标准化-方案制定扩展性功能能力稳定性身份、场景

23. • 技术方案标准二：请求处理标准化-参数透传自研 QShareData 组件  场景1：参数小数据透传  场景2：结果大数据回传  扩展：跨页面参数携带

24. • 背景与现状 • 基于DDD思想的规划 • 落地步骤 • 思考与总结

25. • 总结与思考  康威定律：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构  业务架构康威定律成立说明组织架构与系统之间必须匹配，但未强调合理  DDD中的康威定律：系统架构驱动组织架构。DDD基于业务领域，回归业务，与业务匹配，更容易做到合理组织架构系统架构

26. • 总结与思考 Q：团队如何划分才能与业务匹配？ A：让DDD的制约因素成为DDD要改变的目标  以DDD得到的业务领域模型为基础，审视与调整组织架构，进行团队的划分  从业务领域结构出发形成网状组织架构，并在业务发生显著变化时保持组织架构的灵活性，反向使康威定律发挥作用

27. • 总结与思考 DDD能给我们带来什么？推动业务架构？ DDD->系统架构 DDD->组织架构

28.

29.