"架构全集"与"架构整体"的区别，及时间/空间需求的成本控制价值

当系统规模扩展到多个领域、需要架构师团队分头处理各自领域的架构时，一个容易被忽视的问题浮现出来：”架构整体”本身是不是也需要独立的架构决策？作者论证答案是肯定的，理由建立在区分”架构全集”与”架构整体”之上。如果架构只谈各领域各自的目标需求、不谈时间需求与空间需求，那么”架构整体”就只能等效于”各种（领域）架构的简单加总”——但如果这个加总里的各个元素之间没有建立关系，”全集”这个说法本身就已经破坏了”整体性”（一堆互不相关的领域架构拼在一起，称不上一个真正的整体）。进一步，架构本来就应该通过解决问题来实现需求，而非单纯响应需求——如果只谈各领域的目标需求，就完全触及不到需求背后真正的问题；而时间需求与空间需求背后对应的问题是清楚的：系统的规模与复杂性。作者由此指出架构本身真正的价值在于”在保持方向的同时控制成本”，而对时间需求与空间需求的考量，正是让”架构全集”提升为”架构整体”的价值所在——因为只有引入时间和空间维度，才能把架构拆解成多个阶段（对应实施阶段）去迭代推进，从而实质性地解决规模和复杂性问题、达成成本控制。这解释了为什么”架构整体”需要一个独立的角色（首席架构师/系统架构师）去专门决策：这个角色面对的不是各个独立领域内部的具体问题，而是如何把一堆分散的领域架构真正粘合成一个有时间/空间结构、成本可控的整体。可迁移启发：判断一份”系统整体架构”是否只是各子系统架构文档的简单堆砌，可以检查它有没有明确谈到时间维度（分几个阶段迭代、每个阶段解决什么规模的问题）和空间维度（各部分的边界与相互关系）——如果只是罗列了各个子系统各自的目标需求，而没有这两个维度的统筹，那么它称得上”架构全集”，但还算不上真正意义上的”架构整体”。