DDD 领域驱动设计 实践02

本文讲述了新垂直交易系统从烟囱式架构演进到组件化、中台化的过程,强调了领域驱动设计(DDD)在其中的作用。通过提炼业务知识、明确架构设计以及持续重构,实现了业务领域的拆分和系统微服务化。通过识别限界上下文、服务分解与整合,促进了服务间的解耦和独立性。在实践中,使用领域模型来指导系统设计,提高团队协作效率,推动系统持续演进。
摘要由CSDN通过智能技术生成

一、新垂直交易系统演进的背景

烟囱式

15年初, O2O上门服务(保洁、推拿等等)进行的如火如荼,行业内涌现了数个估值上亿的到家服务公司。O2O的重要玩家,点评希望通过对接这类公司为用户提供服务。作为平台方,需要在短期内接入尽可能多不同品类的第三方。公司从新垂直团队和搜索团队紧急抽调数十人团队进行研发。此时,研发和产品同学均只负责过信息线业务,无任何交易业务的经验。通过一个月的紧张研发,业务顺利上线。到家业务先后接入了近百家第三方。

随着业务的日渐成熟和战略方向的不断调整,新垂直团队先后负责了汽车保养服务、鲜花配送、健身私教预约、齿科预订和搬家预订等业务。其中,鲜花配送和健身私教预约在进行产品的MVP研发之时就已经确定业务上线之后要移交给兄弟团队负责。这些业务无一例外使用了烟囱式的架构,每个业务独立的web和service项目进行部署。这种架构使得团队在交易系统经验较少的情况下,快速上线业务。面对组织架构的调整,系统也能快速移交给兄弟团队。

组件化

交易系统外部依赖较多,每个业务都依赖于统一订单、结算等数十个中台系统。随着业务的发展,团队负责的交易系统就会越来越多,如果每个外部依赖都单独对接,系统里就会出现大量相同的代码、相同的存储结构。当外部依赖变更时,各个独立的系统都要进行相应的调整。例如我的订单中心为了支持m站,原先的SPI里面新增一个接口,每个业务系统都需要重新实现、打包、部署。

针对重复对接的痛点,我们抽象出统一对接的组件,负责与中台系统对接,对每个业务屏蔽对接的细节。当中台的对接方式发生变更时,业务无需关心,仅对接组件做相应的变更即可。通过这种架构,我们支持了乐车邦、即刻达和购物See业务的快速上线。

中台化

随着业务的快速发展,团队成员对交易系统也有了一定的经验积累,我们也不满足于仅外部依赖对接的组件化,寻求更高层次的复用。恰逢公司提出中台化战略,通过中台化,可以达到更高的复用,更高效地支撑业务快速发展。

     原有采用烟囱式和组件化架构的系统,每个业务都有自己独立的模型。随着需求的迭代,每个模型都在独立地演进,业务知识散落在各个模型中。我们认为实现中台化的前提是对业务领域知识有统一概念上的理解,为此需要对原有系统的业务知识做更进一步的提炼,使用统一的业务知识来支撑各个业务。

领域驱动设计(Domain Driven Design,DDD)就是一种可以从多个业务中沉淀和提炼知识,抽象复杂业务,并指导实现的方法论。通过领域驱动设计,可以:

  • 使团队统一语言,准确表达业务知识,做到知识共享,培养领域专家;

  • 指导服务的拆分与合并,为交易系统中台化建设提供理论指导。

二、领域驱动设计实践

通过使用DDD的战略模式,帮助我们深入理解面临的业务问题域,明晰团队的业务边界,提炼领域知识,进而根据功能维度将领域分成多个子域;DDD中的限界上下文可以帮助我们结合平台中台能力构建微服务,针对原有系统进行拆分合并重构,在服务内将业务逻辑规则与技术解耦,利用多个微服务构建初步的新垂直交易系统体系;在后期的业务发展过程中,以领域模型为团队交流和系统设计的基准,持续演进。

1 提炼领域知识

提炼领域知识,首先要识别出团队的业务领域范围,在范围内提炼出领域模型,再将大的模型进行分解,从而解构问题域。同时,让整个团队基于一致的业务语言进行沟通,提高了团队效率,将为下一步的系统设计、实现和演进提供指导。

1.1 确定业务领域边界

新垂直交易业务范围涉及爱车、医疗和宠物三个SBU,除了支撑有支付功能的交易场景外(齿科预订、宠物电商等),也包括各种非支付的交易场景,如在线咨询、免费预约、抽奖、线上下单线下支付、团购后预订等场景。基于支付的常规交易需求,大多可以由交易中台团队承接,部分功能也需要业务方支持,个性化较重的交易需求由业务方团队自己开发。团队的交易业务边界并不总是清晰可见的,也会与周边业务渗透耦合,但尝试划分业务边界总能够帮助到我们,边界的划分决策需要站在更高的层面、更大系统的角度来看。

1.2 提炼业务领域

业务知识的提炼贯穿项目始终,我们经常使用用例驱动设计的方法,来做需求的分析提炼。

用例驱动设计是一种由外而内的思想,直接反映了业务的现状,只要实现了一个个业务场景,就能满足涉众对于系统的期望,就能取得系统的成功

该方法输出的设计文档称之为用例模型。当团队在承接更多的交易型产品需求时,慢慢感觉到了用例模型的离散性,业务知识被局限于一个个用例中。业务知识的分散使得团队沟通变得效率低下,研发人员难以对不同产品的多个交易系统做整体的抽象。

用例模型的不足,恰恰是领域模型的强项,

领域模型是对业务知识的抽象,识别出业务中重要的业务实体及其关系,反映了业务的本质结构

所有团队成员都可以围绕领域模型展开沟通,并将业务知识不断反馈到领域模型中。分层次的领域模型更加符合人的心智模型,有利于让开发人员从纷繁复杂的业务逻辑和规则中解脱出来。

新垂直交易系统在不断演进的过程中,将领域模型和用例模型结合使用,总结出了一套提取领域知识提取流程。在初期得到了领域知识的整体概貌,在后期对模型进行精炼,得到更深层次的见解。

领域模型通常以术语表和图形化两种方式展示。

收集和定义术语

术语代表了业务中的核心概念,术语间的关系也能反映出部分业务过程,掌握术语表是对系统进一步

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值