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

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-13 19:41
浙ICP备14020137号-1 $bản đồ khách truy cập$