加尔定律
能正常工作的复杂系统，往往由一个能工作的简单系统逐步演化而来。
显示原始英文内容
Gall's Law
A complex system that works is invariably found to have evolved from a simple system that worked.
Takeaways
- Don't build a complex system from scratch. Instead, make a simple version that works, then iterate and add complexity. This approach serves as a launching pad for experimentation and innovation.
- Successful large systems often grow organically. A fully designed-from-scratch complex system usually fails because you can't foresee all interactions.
- This law argues for creating a Minimum Viable Product (MVP), a simple working core, and then growing it, rather than a big-bang approach.
- Systems that grow tend to adapt and handle complexity better because they've been tested and refined at each stage. An overly complex initial design can break when something unexpected happens.
Overview
John Gall observed that successful complex systems start as successful simple systems. If you attempt to create a complex system from the beginning, it usually doesn't work because there are too many unknowns you haven't validated.
Instead, start with a simple architecture and learn from real-world usage. Add features or complexity incrementally, ensuring each change still works. When you start with a small, functional core, you can validate assumptions early. Every new capability added incrementally is tested against reality, forcing the system to adapt.
Examples
Facebook started as a simple website for Harvard students. It was essentially a basic user profile system that worked at that small scale, then expanded gradually, adding features and handling more users. If Mark Zuckerberg had tried to build today's Facebook from scratch in 2004, it would almost certainly have collapsed under its own complexity.
In the era of microservices, a common piece of advice influenced by Gall's Law is: don't start with microservices. Start with a monolith (a simpler architecture) that works. As it grows, identify pieces to split off into separate services. Those pieces have the benefit of prior existence, you know their requirements from the monolith, and thus are more likely to work once isolated.
Origins
John Gall, an American pediatrician with a sideline in systems theory, published *Systemantics: How Systems Work and Especially How They Fail* in 1975. 30 publishers initially rejected the book before it became a cult classic.
The third edition (2002) of the book is named *The Systems Bible*.
核心含义
复杂系统很难一次性被准确设计出来。一个简单的原型先在真实环境中运行，团队才能通过反馈了解真正的边界、负载和使用方式，再逐步演化出更复杂的结构。
这条规律鼓励增量演进，也提醒我们保留可替换的边界，不要一开始就把所有未来需求编码进系统。
实践例子
先用一个清晰的单体服务验证业务流程，随着团队和流量增长，再根据真实的耦合点拆分服务，通常比从第一天就设计几十个微服务更稳妥。
来源与边界
它来自系统理论家约翰·加尔对复杂系统演化的观察。原型必须足够简单但确实可运行；“先做简单版本”不等于忽略安全、数据一致性等不可逆约束。