计算机科学家 Alan Kay（面向对象之父）：

"Simple things should be simple, complex things should be possible."

（简单的东西应该保持简单，复杂的东西应该成为可能。）

一、 极简与控制复杂度（Simplicity & Complexity）

1. C.A.R. Hoare（图灵奖得主，快速排序算法发明者，ALGOL 语言设计者）

"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complex that there are no obvious
deficiencies."

“软件设计有两种方式：一种是让它简单到‘明显没有缺陷’；另一种是让它复杂到‘没有明显的缺陷’。”

2. Antoine de Saint-Exupéry（《小王子》作者，虽然是作家，但这句话被工程界誉为设计最高法则）

"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."

“完美不是加到无法再加，而是减到无可再减。”

—— Unix 哲学与 Go 语言设计理念的灵魂基石：好的设计永远在做减法。

3. Brian Kernighan（C 语言与 Unix 传奇巨擘，《C 程序设计语言》合著者）

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."

“调试代码的难度是写代码的两倍。因此，如果你写代码时穷尽了所有的聪明才智（去炫技），那么按定义来说，你就不够聪明去调试它。”

二、 易用性与降低心智负担（Developer Experience）

4. Martin Fowler（《重构》、《企业应用架构模式》作者，软件设计大师）

"Any fool can write code that a computer can understand. Good
programmers write code that humans can understand."

“任何傻瓜都能写出计算机看得懂的代码。只有优秀的程序员才能写出人类看得懂的代码。”

5. Rob Pike（Go 语言首席设计师，Unix 核心成员）

"Simplicity is hard to build, easy to use, and hard to charge for.
Complexity is easy to build, hard to use, and easy to charge for."

“简单：构建起来极其困难，用起来极其轻松，却很难卖出高价。复杂：构建起来很容易，用起来极其痛苦，却很容易开出高价。”

三、 架构设计的终极目标（Pragmatic Engineering）

6. Rich Hickey（Clojure 语言设计者，极简主义架构大师）

"Simplicity is a prerequisite for reliability."

“简单，是可靠性的先决条件。”

—— 系统越复杂，不可控的隐患就越多；想要系统 99.999% 稳定，唯一的途径就是把结构设计得足够简单。

7. Edsger W. Dijkstra（图灵奖得主， Dijkstra 算法发明者，结构化编程奠基人）

"Simplicity is prerequisite for reliability. Simplicity is also the
ultimate sophistication."

“简单是可靠的前提，简单也是最高级的复杂。”

（这句话后半句源自达·芬奇的 "Simplicity is the ultimate sophistication"）

摘要：为什么企业级系统越维护越难改？本文不谈虚无缥缈的架构哲学，而是从本质复杂性识别、模块化颗粒度权衡、以及状态管理三个实战维度，探讨如何在长期演进中夺回系统的控制权。记住：可预测性远比灵活性重要。

在长期维护企业级中后台系统或信息化平台时，我们常陷入一种无力感：系统随着时间推移变得越来越难以理解和修改。这种“软件熵”的增加，本质上不是代码写错了，而是复杂性失去了控制。

如何破解？我们需要建立一套对抗熵增的思维框架。

重新定义“必要的复杂性”：学会剪枝

控制复杂性的第一步，往往不是增加抽象层，而是做减法。我们需要严格区分两种复杂性：

本质复杂性 (Essential Complexity)： 由业务逻辑本身决定（如税务计算规则、审批流转），无法通过技术手段消除。
偶然复杂性 (Accidental Complexity)： 源于过度设计、过时的依赖、不一致的接口定义，或是为了“未来可能的需求”而预留的冗余。

💡 架构师笔记：警惕“抽象陷阱”

❓ 灵魂拷问：这个 AbstractFactoryBean 真的解决了当下的问题，还是仅仅增加了一个我需要维护的概念？

实操建议：
在进行任何重构或新设计前，执行 “YAGNI 审查” (You Ain't Gonna Need It)。如果一个抽象层在当前没有至少两个具体的实现类，或者其存在的唯一理由是“解耦”，请大胆删除它。好的架构是演进而来的，不是预先设计出来的。

模块化的颗粒度：在单体与微服务之间寻找平衡点

在 Java/Spring Cloud 技术栈下，微服务拆分极易走入极端。过细的拆分不仅不会降低复杂性，反而会将“代码内的复杂性”转移为“分布式系统的复杂性”（如分布式事务、网络延迟、链路追踪成本）。

🎯 推荐策略：模块化单体优先 (Modular Monolith First)

不要急于物理拆分，先在逻辑上建立防火墙：

DDD 边界先行： 在单体内部通过包结构、Maven Module 或 Gradle Project 进行严格的领域隔离。
API 契约化： 模块间禁止直接访问数据库表或私有类，必须通过显式的 Service/API 交互。
按需剥离： 只有当某个领域的迭代频率或资源消耗远超其他领域，且成为团队瓶颈时，才考虑将其物理剥离为独立服务。

状态管理与副作用：追求极致的“可预测性”

复杂的 Bug 90% 源于共享状态的混乱和隐式副作用。一个容易预测的系统，才是好维护的系统。

🛠️ 降低心智负担的三个抓手

拥抱不可变性 (Immutability)： 尽可能使用 Record (Java 16+) 或 Lombok @Value。不可变对象天然是线程安全的，且消除了“谁在什么时候修改了它”的认知负担。
显式化副作用： 将纯业务逻辑（计算、校验）与副作用（DB写入、消息发送、RPC调用）分离。让核心领域服务保持纯净，将副作用推向应用服务层或基础设施层。
善用数据库特性： 不要把所有并发控制都放在应用层。合理利用 PostgreSQL 等数据库的事务隔离级别、行级锁或 Advisory Lock，让数据层成为一致性的最后一道防线。

⚠️ 核心原则：可预测性 > 灵活性。
灵活意味着多变，多变意味着意外。在企业级系统中，一段“无聊但确定”的代码，永远胜过一段“聪明但晦涩”的代码。

复杂性控制不是一次性的架构设计，而是一种持续的工程纪律。它要求我们在每一次提交代码时，都能克制住“炫技”的冲动，回归到业务价值的本质。

你的系统不需要更多的抽象，它需要更少的意外。