瀑布模式导致需求、设计、实现割裂的信息丢失问题

在单机和集中式架构时代，软件建设普遍采用瀑布开发模式，系统分析、设计和开发被拆成独立的、依次接力的几个阶段：一人负责提出需求，另一人负责需求分析，再一人负责系统设计，最后一人负责代码实现。这个链条越长、经手的人越多，信息在每一次交接中失真或丢失的概率就越大——最终常见的结果是软件上线后才发现做出来的功能和最初的需求偏差很大，”这不是我想要的”。这个案例揭示了一个不限于软件工程的通用规律：当一项工作被拆分成多个角色依次接力完成、且每次交接主要依赖文档或口头转述而非持续的直接协作时，每一次交接本身就是一次信息保真度的损耗，链条越长损耗越明显，最终产出和最初意图之间的偏差会随环节数累积放大。这也是本书后续强调DDD要求项目团队与领域专家持续协作、用”通用语言”减少沟通损耗的深层原因——不是流程细节上的偏好，而是从根源上缩短信息传递链条、避免瀑布模式这类多环节接力必然带来的信息衰减。