反DDD模式之“复用”
本文书接上回《反DDD模式之关系型数据库》，关注公众号（老肖想当外语大佬）获取信息：
-
最新文章更新；
-
DDD框架源码（.NET、Java双平台）；
-
加群畅聊，建模分析、技术实现交流；
-
视频和直播在B站。
背景
在我们软件开发过程中，“复用接口（webapi）”、“复用服务（service）”是非常常见的现象，很多老司机都会为自己设计的代码可以“复用”而感到有成就感。然而当我们在一个较长的时间周期去看待系统的迭代过程，会发现这些“复用”，往往会成为后来迭代的绊脚石，修改代码牵一发而动全身，细微的修改也会引发广泛的影响面，从这个角度看，“复用”是不利于系统的可维护性的。
今天我们就来深度探讨一下“复用”和DDD之间的关系，打开一个不同的视角。
复用的本质
下图展示了一个非常典型的复用例子，不少开发者习惯提供一个“保存接口”来满足“创建”和“编辑”场景：
按照我们的惯例，“连线”代表着“耦合”，所以“复用”接口，本质上就是把不同的业务场景耦合在了一起，当一个场景发生变化时，同时会影响到其它场景。
进一步地推导，两个元素的耦合即打破它们的边界，它们因为耦合而成为了一个更大的整体：
而DDD的价值观是保持明确的边界，打破边界则与之完全相反，因此可以得出打破边界即反DDD：
把上面的推导过程整合在一起就是下图这样：
去掉中间过程，最终我们得出标题的的结论“复用”是一种“反DDD模式”：
限定条件
另外一方面，“复用”一词的含义还是比较广泛的，例如我们有两个系统，A系统和B系统都调用某家的“支付接口”，这算不算复用“支付接口”呢？在我们今天讨论的角度看，这不算复用，因为都是“支付场景”调用“支付接口”，场景其实是同一个。
那么我们需要限定一下范围，这里探讨的复用是指：为不同的场景或者目的所做的复用。基于这个范围我们可以看到一些典型的复用案例：
-
RestfulAPI复用
-
后端服务复用
-
业务中台复用
而这些场景，我相信很多老司机都有过痛彻心扉的体验，复用一时爽，迭代火葬场。
不要复用
基于前面推导的认知，我们知道复用作为反DDD模式，并不会为我们带来价值，反倒会使得系统丧失可维护性，因此我们在实践DDD过程中总结了一些原则，其中重要的部分就是“不要复用”：
-
为每个前端场景创建一个API；
-
为每个API创建各自的输入输出实体（RequestDto、ResponseDto）；
-
为每个操作创建各自的命令（Command）；
下面贴出DDD原则的文档和截图：
https://netcorepal.github.io/netcorepal-cloud-framework/rules-of-ddd/rules-of-ddd/
实战项目
目前开源DDD实战项目d3shop已经启动了，你可以自由地参与需求讨论、建模设计、代码贡献中来，我们每周都会针对模型设计、代码做直播评审和连麦讨论，从而帮助你更沉浸地体验DDD实践带来的成长和收益。
