一套使用 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