DDD实践反思

某大型互联网公司于2019年开始在XX中台财务域进行DDD实践。事后回顾，整体并没有达到预期的效果，个人也做了很多的反思和总结，形成此文。

1. 背景

为什么当时要实践DDD？其中的缘由比较复杂，可以从外部和内部两个视角来看。

首先，从外部也即整个BU的视角来看，最先开始实践DDD的是A域，并在该域诞生了一套在公司现有RPC框架之上的业务SPI框架（以下简称为【N框架】）。相较于dubbo这样纯技术的服务框架，它有以下特点：

• 标榜serverless，自身提供了代码托管和运行容器，可以直接进行服务的开发、部署及运维，也可以将现有docker应用的服务以SPI的形式注册到这个框架上并发布，实现“服务市场”的效果
• 可以进行服务的热插拔，不停机升级回滚不同版本的服务
• 业务SPI管控，可以将SPI按照业务域划分到不同的路径下，方便管理和业务发现、服务编排

在BU内部推行N框架时，对于现有的应用，需要将核心服务用SPI的方式注册上去；对于新接入的业务，则推荐使用serverless形式的bundle提供服务。对于哪些是“核心服务”，这些“核心服务”是否足够标准化，亟待一轮梳理甚至重构。

其次，从本域来看，在组织架构调整后，线上同时运行的多套系统已经日渐成为瓶颈。由于历史原因，XX中台财务域对接多个业务域时，往往会新搭一套系统，造成了当时一共有五套财务系统运行在线上，系统间相互依赖，系统内又有大量的if...else硬编码来处理定制化的需求。在这种情况下，无论对于新业务、新需求的支持，还是对于现有业务的运维，都需要付出巨大的人力成本，并且存在着很多隐患，多版本归一化迫在眉睫。

因为供应商发票在整个财务域的最下游，相对比较独立，并且对于现有的系统业务方也有开票流程线上化的诉求（原先的流程存在大量的人工步骤：是将对账单导出为excel，导入到开票系统，然后再将开票结果数据导回系统），所以选定了供应商发票这个子域作为第一个试点，目标是新建一套销项发票系统，发布可扩展的SPI，并将已有的业务线流量逐步切过来，降低运维成本，提高研发效率。

2. 实践

2.1 布道

对于DDD，其中有很多的概念和方法，需要所有开发认知达成一致，这里就不重复那些经典的概念了。

这里想稍微聊一下”六边形架构“。为什么是六边形，不是正方形、五边形、八边形？我思考了很久，得出的结论是：六边形比较好看，而且也好画。具体这六个边除了表示边界，并没有什么实际的含义，比如六大金刚什么的。使用”六边形架构“，一是为了和传统的分层结构进行区分，二是为了表示这个系统不是孤立的，而是在一个大网格中的一个节点。

对于实体，最初我的理解是现实中存在的对象，在DDD里则被定义为”有标识符来区分的对象“。从哲学的角度，则是”是客观存在并可相互区别的事物“。这样理解思路就开阔多了， ”订单“是实体，”抽奖活动“也可以抽象为实体[1]。

需要注意的是，一定要遵守现有的或形成一套统一的命名规范。比如DO，一般指的是DataObject，但是DomainObject也能缩写成DO，是不是很神奇？

2.2 建模

首先使用用例分析法，分析现有系统+短期未来中需求的用例。“发票”这一实体在现实世界中相对固定，所以建模相对比较简单——实际上并不完全正确，并且这种思维定式为后续的建模和开发带来了隐患。在子域划分中可以看到，不仅仅只有一个发票实体。

但是仅通过用例分析，又显得比较单薄——甚至很多业务场景都能套进这个模板中，因此需要在后续的环节（分析流程中缺失的实体ÿ