从 ABP 到 CleanDDD：关于软件长期演进的一些思考

---

从 ABP 到 CleanDDD：关于软件长期演进的一些思考

最近在项目中接触到了 CleanDDD，也重新审视了我们长期使用的 ABP 技术栈。

这并不是一篇“反 ABP”的文章，而是一次站在时间维度上的技术反思。

如果你也在维护一个已经运行多年、并且还会继续演进的系统，或许会对下面的内容产生共鸣。

---

一、站在时间轴上看软件开发的变化

如果把时间拨回十年前，软件开发面临的核心问题其实很简单：

• 有没有系统
• 能不能尽快上线
• 能不能稳定跑起来

在那个阶段，交付本身就是最大的价值。

但今天，情况已经完全不同了。系统不再稀缺，真正昂贵的反而变成了：

• 系统维护成本
• 需求频繁变更的风险
• 人员流动带来的不确定性
• 业务规则不断叠加后的复杂度

软件开发的核心矛盾，已经从：

“能不能做出来”

转变为：

“还能不能持续演进”

---

二、CleanDDD 在解决什么问题

很多人第一次看到 CleanDDD，会觉得它：

• 结构清晰
• 分层明确
• 代码“看起来很干净”

但真正让我开始认真看待它的，并不是这些表象。

CleanDDD 真正试图回答的，是一个非常现实的问题：

这个系统在 3～5 年之后，还能不能被安全地修改？

在大量项目中，系统难以维护，往往不是因为业务本身有多复杂，而是因为：

• 业务规则分散在各个角落
• 没有人能说清楚「改这个需求到底该动哪一层」

CleanDDD 做的一件事其实很“笨”，但非常有效：

强制把业务规则收敛到领域层

这不是为了形式上的 DDD，而是为了：

对抗系统复杂度的自然增长

---

三、真正的风险：系统没人敢改

在实际工作中，我越来越觉得一个系统最大的风险，并不是开发速度慢，而是：

关键人员离开后，系统没人敢动

很多系统不是不能改，而是：

• 不知道会影响哪里
• 不确定会不会引发连锁问题
• 最终选择「能不动就不动」

CleanDDD 的一个重要价值，在于它试图把业务知识：

• 从 “人的经验” 转移到 “模型和代码结构” 中

这本质上是在降低组织层面的风险，而不仅仅是技术问题。

---

四、交付速度 vs 长期成功率

快速交付本身没有问题，真正的问题在于：

很多系统只对第一次交付负责

在后期需求中，我们经常看到这样的情况：

• 一个看似很小的改动
• 引发多个模块的连锁修改
• 最终演变成一次高风险操作

CleanDDD 关注的并不是：

“这个功能能不能尽快上线”

而是：

“第 20 次、第 30 次需求调整时，系统还能不能稳住”

这是一次性交付成功，与长期演进成功之间的差别。

---

五、一些非常实际的工程收益

从工程角度看，CleanDDD 带来的变化是非常具体的：

• 业务逻辑只存在于领域层
• 每个聚合都有清晰的职责边界
• 行为具备明确的输入与输出

当需求变化时：

• 你大致知道该从哪个领域模型入手
• 也能明确哪些地方不应该被修改

而这，恰恰是很多 ABP 项目在后期最容易失控的地方。

---

六、为什么 CleanDDD 更适合长期演进的系统

CleanDDD 从一开始的设计目标，就不是：

“这个功能能不能快点上线”

而是：

“五年之后，这个系统还能不能继续加新规则”

一个非常直观的对比如下：

场景	常见 ABP 项目	CleanDDD
新增规则	AppService 中不断加 if	新的领域行为
行为复用	复制业务逻辑	复用聚合能力
业务重构	高风险	局部替换
新人接手	需要较长熟悉期	更快理解业务

---

七、CleanDDD 与 AI 编码的一点关系

这是一个相对新的视角，但我认为非常重要。

AI 编码本质上依赖几件事：

• 清晰的上下文
• 稳定的边界
• 可预测的结构

而这些，恰好都是 CleanDDD 所强调的。

领域模型、统一语言、明确的行为边界，使得代码空间本身是：

低熵的、可组合的

相比之下，典型的 ABP 项目中：

• ApplicationService
• Repository
• UnitOfWork
• 各种框架约定

往往混杂在一起。这种结构对人尚且吃力，对 AI 来说更容易误判上下文。

这不是未来的假设，而是已经在发生的现实。

---

八、关于框架老化的问题

有一句话我越来越认同：

所有框架都会老，但业务不会

CleanDDD 的一个隐性优势在于：

• 框架升级，主要影响基础设施层
• 领域层可以长期保持稳定

而在 ABP 中，领域模型往往：

• 继承框架基类
• 生命周期与框架深度绑定

在 5～10 年周期的系统中，这种差异会被不断放大。

---

九、关于 ABP：不是对错，而是取舍

需要强调的是，这并不是一篇否定 ABP 的文章。

ABP 的设计目标非常明确：

• 快速交付 CRUD 系统
• 提供完善的权限、多租户、审计能力
• 降低团队协作成本

为了实现这些目标，它必然做出一些取舍：

• ApplicationService 权力较大
• Repository 支持灵活查询
• 实体继承框架基类

这些设计，天然更接近事务脚本模型，而不是严格的 DDD。

---

十、为什么 ABP 天然不追求“纯 DDD”

这更多是由历史背景决定的。

ABP 诞生于 2013～2016 年，当时：

• .NET 企业开发以 N 层架构为主
• 系统多为 ERP / OA / 管理后台
• 企业最关心的是交付速度和通用能力

DDD 在国内更多停留在理论层面，并非主流实践。

因此，ABP 的定位从来都是：

企业级应用框架

DDD 只是它兼容的一种思想，而不是第一性原则。

---

十一、一个更工程化的总结

如果把话说得更直白一些：

ABP 解决的是：如何规模化交付软件
CleanDDD 解决的是：如何长期演进业务系统

这并不是谁对谁错，而是面对的问题不同。

---

十二、一个更现实的建议

与其“反 ABP”，不如“驯服 ABP”。

在 ABP 技术栈下，完全可以：

• 用 CleanDDD 构建领域层
• 用 ABP 提供基础设施能力
• 显式使用领域事件
• 避免在 AppService 中堆积业务规则

这可能不是最快的路，但很可能是：

未来几年风险最低的路

---

写在最后

CleanDDD 本质上并不是一种“更高级的写法”，而是一种：

为未来不确定性预留空间的工程选择

在系统复杂度还可控的时候，
为未来 3～5 年留一条安全的演进路径，本身就是一件非常值得投入的事情。

CleanDDD项目地址：
https://github.com/netcorepal/netcorepal-cloud-framework

---