敏捷不是不要文档而是不要过于详尽的文档业务模型要保持简洁抽象才能兼容敏捷

企业级业务架构设计常被认为和敏捷开发天然冲突，作者逐条对照 “敏捷宣言”的核心价值来检验这个疑虑是否成立。第一条容易被 误读的是”工作的软件优于详尽的文档”——敏捷开发以”不重视” 文档闻名，但真相并不是完全不要文档，而是不要那么详尽的文档： 过度详尽的文档会消耗大量精力，实际用途却有限，对开发人员来说， 在软件维护上，一份高质量需求文档远不如整洁代码加详尽注释更 能说清楚软件结构；即便如此，敏捷开发也依然要求有一份恰当的 概括性文档作为项目总体目标，不是什么都不要就直接埋头往前冲。 要消除业务模型和敏捷之间的这层”矛盾”，关键在于业务模型这套 方法自身也必须具备一定的简洁性——业务模型不应该承载太多业务 细节，而要保持适当的抽象度，具体细节该描述到什么程度因企业 而异，但大原则是刚好能解释清楚任务对数据实体的创建和变更， 足以划分任务和组件边界即可。这也带出一条前提区分：企业首次 做企业级转型时，本来就不适合用敏捷方式来做——转型需要深思 熟虑，本身就不是敏捷应该完成的事情；但一旦转型结束、企业级 架构已经建立起来，接下来就变成了”如何快速应用架构工具”的问题 ——保持简洁抽象度的业务模型本身具备快速应用的潜质，它就是一张 “作战地图”，反而能帮助项目更快摸清项目范围、涉及的组件团队 以及潜在的影响，而不是拖慢速度。