架构边界可存在于任何地方，决策不是一次性的而是持续观察演进的成本权衡

把[[HuntTheWumpus案例从三组件模型到多API边界GameRules成为最高层策略]]和[[数据流会随系统复杂化持续分裂高低层策略的拆分要视场景而定]]拼在一起看，一个原本Kornshell 200行代码就能写完的小程序，硬是被展开成一套充满架构边界的复杂结构——这不是鼓励过度设计，而是要证明一件事：架构边界可以存在于任何地方。架构师必须小心审视究竟哪些地方真正需要设计边界，同时也要弄清楚完全实现这些边界会带来多大成本，以及一旦事先忽略这些边界、后续再想补上会有多困难（哪怕有覆盖广泛的测试和小心翼翼的重构，也未必能挽回补边界的代价）。这中间没有标准答案：一方面YAGNI原则提醒我们不该为臆想中的未来需求过度抽象化（过度工程往往比工程不足更糟）；另一方面，如果某处确实需要架构边界却没提前准备，事后补上的成本和风险往往很高。软件架构师因此必须具备一点”未卜先知”的能力——有时得靠有根据的猜测，仔细权衡成本，决定哪里需要架构边界、需要的是完整边界、不完全边界，还是可以完全忽略的边界。而且这不是项目开始时能一次性拍板的决定：架构师必须持续观察系统的演进，随时留意哪里可能需要边界，观察那些地方因为缺边界而暴露出什么问题，权衡实现该边界的成本与不实现的成本，反复对比，找到”设置边界的优势超过其成本”的那个拐点，那才是实现该边界的最佳时机——这份权衡需要持之以恒，一刻不能放松。