系统设计中的复杂性控制：从“软件熵增”到“可预测架构”
摘要：为什么企业级系统越维护越难改？本文不谈虚无缥缈的架构哲学，而是从本质复杂性识别、模块化颗粒度权衡、以及状态管理三个实战维度，探讨如何在长期演进中夺回系统的控制权。记住：可预测性远比灵活性重要。
在长期维护企业级中后台系统或信息化平台时，我们常陷入一种无力感：系统随着时间推移变得越来越难以理解和修改。这种“软件熵”的增加，本质上不是代码写错了，而是复杂性失去了控制。
如何破解？我们需要建立一套对抗熵增的思维框架。
重新定义“必要的复杂性”：学会剪枝
控制复杂性的第一步，往往不是增加抽象层，而是做减法。我们需要严格区分两种复杂性：
本质复杂性 (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，让数据层成为一致性的最后一道防线。
⚠️ 核心原则：可预测性 > 灵活性。
灵活意味着多变，多变意味着意外。在企业级系统中，一段“无聊但确定”的代码，永远胜过一段“聪明但晦涩”的代码。
复杂性控制不是一次性的架构设计，而是一种持续的工程纪律。它要求我们在每一次提交代码时，都能克制住“炫技”的冲动，回归到业务价值的本质。
你的系统不需要更多的抽象，它需要更少的意外。