示例:一套使用 DDDplus 开发的订单履约中台

原创
2020/10/20 23:02
阅读数 1.4K

一套使用 DDDplus 开发的订单履约中台

项目背景

中台部门要实现一套订单中台(OMS),以订单为线索,实现销售订单的物流履约全生命周期管理,支持全渠道、全场景,为多个快速发展的业务前台BP赋能。

通过OMS,使得订单执行过程中的相关系统,例如TMS,WMS,BMS等成为一个有机整体,并为持续优化提供有力的数据支持。

一个订单从提交到最后真正生产成功,需要经历几十个系统,涉及的接口交互、MQ交互可能达到上百个,任何一个环节出问题,都会导致这一单的异常。

该系统对接的上游,即业务前台BP有近10个,每个BP的团队规模和经营规模不同,对新功能交付速度的要求也不同。

本示例仅列举两个典型的BP部门:

  • KA(Key Account),即关键客户,全行业覆盖
    • KA的话语权大,他们往往把内部生产和管理的形态传递(污染)到这套订单中台
    • KA的需求是无法预测的,不确定的,无法自顶向下设计;即使同一个行业的KA,需求也千差万别
    • 每个KA都有一系列的个性化业务,字段要求不同,流程不同,业务逻辑不同
      • 例如,仓储出库打印面单不同,目标出库仓算法不同,库存预占模式不同,生产状态回传节点不同等
  • ISV,独立软件开发商

相对于普通的平台化,中台不仅要解决烟囱式架构问题,还要解决前台、中台组织的问题,本质上它是一个复杂生态下的协作问题。

同时,订单中台本身也有很多个性化的业务,也需要架构设计上支撑,避免补丁式开发。

基本思想

1个中台(CP),支撑多个业务前台(BP),BP复用CP的能力,并能够通过扩展以满足BP的业务场景诉求。

中台是业务能力的入口和赋能者,业务模型和数据模型沉淀在中台。

前台是中台能力的放大器,通过扩展,把中台能力落地到具体的业务场景,同时也是中台能力的来源。

已解决的问题

  • 系统上
    • 一套代码,满足所有场景需求
    • 一套代码,多种打包部署模式,支持国内和国际业务
    • 代码本身知识化,沉淀业务资产
    • 中台的业务代码如何分层设计,层间如何交互,如何让研发拿到需求立刻就知道代码写在哪里,不各显神通地造轮子造概念
    • 如何快速响应千奇百怪的个性化需求,同时保持自身不腐化
    • 一套模型,如何消化大量的个性化字段
    • 中台如何控制多前台业务包的风险,jar冲突,被拖死等问题
  • 组织上
    • 前台、中台如何解耦,如何协同发展,如何速率匹配
    • 前台如何复用、编排中台能力,如何扩展中台能力来实现自助式发展
    • 支持前台、中台协同开发,前台可以方便地使用和扩展中台能力,独立实现市场需求

更详细信息

请查看 dddplus-demo code

展开阅读全文
tms
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部