不完全边界"省掉最后一步"策略，及FitNesse的成功兼反例

构建完整的架构边界很昂贵——要设计双向多态边界接口、输入输出数据结构、管理所有相关依赖关系，把系统分割成可独立编译部署的组件，前期工作量大、后期维护成本也不小。架构师明知未来可能需要某条边界、却又觉得现在就完整实现代价太高，这种预防性设计在敏捷社区常被批为违反YAGNI原则（”不要预测未来的需要”）；但预见性设计本就是架构师工作的一部分，”不完全边界”正是为这个矛盾找到的折中方案。最简单的不完全边界策略是”省掉最后一步”：把系统按接口、输入输出数据格式都设计成可独立编译部署的组件，但最后仍选择把它们统一编译部署成一个组件——这样做所需的代码量和设计工作量与完整边界完全一样，只是省掉了多组件管理、版本号管理、发布管理这部分工作。这正是FitNesse早期的策略：团队在设计之初就把Web服务器组件设计成独立于wiki和测试部分（预想未来可能用这个Web组件构建其他应用），但为了坚持”下载即可执行”的目标（用户只需一个jar文件，不必操心版本兼容），最终把它们统一打包成一个组件。这个案例同时也是一个警示：随着时间推移，团队慢慢发现独立Web组件的实际需求越来越少，Wiki组件和Web组件之间的隔离也随之弱化——到后来真要把Web组件重新分离出来，反而需要不小的工作量。这提醒我们：不完全边界省下的成本，也可能随着预留的隔离意图逐渐被日常开发侵蚀而打了水漂。