架构定义的完成标准是风险已缓解而非架构完美

架构工作没有”做到完全正确”这回事——在代码写出来之前，正确性本来就很难验证，一直抠细节只会浪费本可以用在别处的精力。判断架构定义是否可以停下来的标准，不是内容是否完整详尽，而是让项目失败的重大风险是否已经被识别并缓解：评审时如果利益相关者不再提出重大异议，就说明可以往前走了。目标是做出”足够好、能满足需求”的架构，而不是追求完美版本，后者的边际投入换不来利益相关者的真实收益。发散：这是”完成好于完美”在架构决策上的具体应用，也是判断”什么时候可以停止设计、开始动手”的通用尺子。