基于 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.