长久以来，我们都在尝试找到一种架构，能够解决代码长久发展、维护的难题。
无论是分层架构、还是整洁架构都是不错的选择，但其发展年限相对于人的发展年限是渺小的，为什么我们不套用人来解决软件系统架构呢？
如果把软件系统当成一个人：类人软件架构（HOA）的思考
很多系统不是“写崩的”，而是“活成了没人敢动的样子”。
如果你维护过一个三年以上的系统，大概率会有这种感觉：
- 功能还能跑
- Bug 也能修
- 但一改核心逻辑，所有人都开始紧张
我们尝试过分层架构、整洁架构、DDD，但问题依然反复出现。
于是我开始思考一个问题：
为什么我们的软件系统，始终不像一个“生命体”？
一、问题不在技术，而在“理解系统的方式”
传统架构大多从技术视角出发：
- Controller / Service / Repository
- UI / Domain / Infrastructure
这些划分在“刚开始”时都很优雅，但随着时间推移：
- Controller 变成了上帝
- Service 里堆满业务
- 状态到处流动
- 边界逐渐消失
问题的根源，并不在于这些架构本身不好，而在于：
它们对人的直觉不够友好。
二、一个反直觉但自然的想法：把系统当成一个“人”
人类是我们已知的最成功的复杂系统之一：
- 结构清晰
- 分工明确
- 能处理异常
- 能长期演化
那如果：
我们不再从“分层”出发，而是直接把软件系统当成一个人，会发生什么？
这就是 类人软件架构（Human-Oriented Architecture, HOA） 的起点。
三、系统即人，模块即器官
在 HOA 中：
一个软件系统 = 一个完整的人
这个“人”是封闭的、安全的，外界不能随意触碰其内部。
器官与架构的映射
| 人体器官 | 架构角色 | 职责 |
|---|---|---|
| 皮肤 | UI / 表现层 | 用户交互与反馈 |
| 骨头 | 骨架结构 | 稳定结构、占位 |
| 嘴巴 | 接口层 | 接收输入、协议转换 |
| 手 | 用例层 | 表达用户意图、编排流程 |
| 胃 | 业务核心 | 业务规则与计算 |
| 脑 | 状态与决策中心 | 全局状态、复杂判断 |
| 下丘脑 | 调度中枢 | 流程编排与指令下发 |
| 肾 | 错误处理系统 | 异常过滤、自愈 |
| 血管 | 数据通道 | 数据与事件流动 |
这种映射不是比喻玩笑，而是强约束的职责划分。
四、一次用户操作，在“人体系统”中是如何完成的
以一次普通操作为例：
- 用户通过 皮肤（UI） 产生操作
- 输入经 嘴巴（接口） 进入系统
- 手（用例） 理解用户想做什么
- 下丘脑 负责调度流程
- 胃（业务核心） 执行业务规则
- 脑 更新状态、做出决策
- 肾 处理异常与错误
- 数据经 血管 返回
- 皮肤 展示最终结果
每一步都清晰、可追踪，也不可越权。
五、为什么这个模型“不容易写烂”？
HOA 天然规避了一些常见反模式：
- ❌ Controller 写业务逻辑（嘴巴不能思考）
- ❌ Service 变上帝（胃只负责消化）
- ❌ 全局 try-catch（错误有肾）
- ❌ 状态满天飞（只有脑能统一决策）
当你用“人体”去审视代码时，很多坏味道会本能地让人不适。
六、它和 Clean Architecture / DDD 是什么关系？
HOA 并不是要取代这些成熟架构。
更准确地说：
Clean Architecture 告诉你“代码怎么分”， HOA 帮你理解“系统应该长成什么样”。
它是一种更高层次的架构认知模型（Mental Model） 。
七、适合与不适合的场景
适合：
- 长期演进的大型系统
- 前端复杂状态系统
- 数据密集、强编排场景
不适合：
- 一次性脚本
- 极小型 Demo
- 对架构约束要求不高的项目
八、写在最后
好的架构，不是看起来聪明，而是像生命一样自然。
类人软件架构不是银弹，也不是框架。
它只是尝试用人类最熟悉的系统——我们自己， 帮助我们在软件复杂度面前，保持清醒与克制。
如果它能让你在写代码时，多一次“这像不像一个健康的人”的自问， 那它的目的就达到了。
