单向边界（策略模式）与门户模式：两种更简化的不完全边界

除了[[不完全边界省掉最后一步策略及FitNesse的成功兼反例]]，还有两种更简化的不完全边界实现方式。单向边界用的是传统策略模式：Client通过一个由ServiceImpl类实现的ServiceBoundary接口来使用服务——这个结构已经为未来构建完整架构边界打好了基础（把Client和ServiceImpl隔离所需的依赖反转已经做完了），但因为没有采用双向的反向接口，图中用虚线标出的位置随时可能出现隔离被打破的风险，只能依靠开发者和架构师的自律来维持组件间的持久隔离——这是完整双向边界（需要持续长期投入资源维护两侧隔离性）和完全不设边界之间的一个中间态。门户模式（facade pattern）则更进一步简化：连依赖反转的工作都省了，边界完全由一个Facade类来定义，这个类背后是一份包含所有服务函数的列表，负责把Client的调用转发给Client看不见的具体服务函数。但门户模式的代价也更明显：Client会传递性地依赖所有Service类，在静态类型语言里，这意味着对任何一个Service类源码的修改都会牵连Client重新编译；而且这种结构里要建立反向通道（也就是升级成真正的架构边界）也相对容易。三种不完全边界策略（省掉最后一步、单向边界、门户模式）各有成本收益、各有适用场景，都可以当作最终完整架构边界的临时替代品，如果事后证明这条边界根本没必要存在，也能自然被降解掉——架构师的职责之一，正是预判未来哪里可能需要架构边界，并决定该用完全形式还是不完全形式来实现它。