冲破架构边界 三种便捷却高效的成功方法！

构建完整的架构边界的老本是很高的。须要为系统设计双向多态的边界接口、输入和输入数据结构以及一切必要的依赖治理，以便将两个局部隔离为可独立编译和部署的组件。这触及少量的上班和前期保养。

许多状况下，一个好的架构师或者会以为设置这样的边界的开销太高，但依然宿愿为或者须要的边界留下位置。

这种预判性设计经常被矫捷社区中的许多人指摘为违犯 YAGNI(你不会须要它)准则。但是，架构师或者会看到疑问并想到:“是啊，但是我或者会须要’在这种状况下，他们或者会成功一个不齐全边界。

结构不齐全边界的一种方法是 将系统宰割成一系列可以独立编译和部署的组件，之后再把它们组分解一个组件。 换言之，将相应的接口和输入/输入数据结构都设置好，并且一切都已预备得当，但咱们仍选用将这些组件编译和部署为单个组件。

显然，这种不齐全边界须要与齐全边界雷同数量的代码和设计上班。但是它不须要治理多个组件。没有版本号跟踪或颁布治理累赘。这一差异不容漠视。这是 FitNesse 的早期战略。FitNesse 的网络主机组件被设计为可与 FitNesse的 wiki 和测试局部分别。这样，咱们就可以经常使用该网络组件创立其余基于 Web 的运行程序。同时，咱们不宿愿用户下载两个组件。请记住，咱们的一个设计目的是“下载并运转”。咱们的用意是用户下载一个jar 文件并口头它，而不用寻觅其余 jar 文件，处置版本兼容性等疑问。

FitNesse 的阅历也提醒了这种形式的其中一个危害。随着期间的推移，人们逐渐意识到不再须要独自的 Web 组件，Web 组件和 wiki 组件之间的分分开局变得软弱。依赖相关开局朝着失误的方向交叉。如今，从新分别它们或者会是一项繁缛的义务。

齐全成熟的架构边界经常使用双向边界接口来坚持双向隔离。保养这种双向的隔离性，通常不会是一次性性的上班，须要咱们继续投入资源。

图 24.1 显示了一个更便捷的结构，用于临时保管裁减为齐全边界的位置它展现了传统的战略形式。serviceBoundary(服务边界)接口由客户端经常使用并由 serviceImpl(服务详细成功)类成功。

上述设计显然为未来的架构边界打下了基础。为了将 Client(客户端)与ServiceImpl隔分开来，必定启动必要的依赖反转。同时，咱们分明看到分别或者会相当迅速地升级，如图示中的恶意虚线所示。因为没有双向接口，除了依赖开发人员和架构师的勤勉和自律，没有任何事物可以防止这种反向通道的产生。

一个更便捷的边界是外观形式，如图24.2所示。在这种状况下，不须要经常使用依赖反转。该边界仅由 Facade(外观)类定义，该类将一切服务列为方法，并将服务调用部署到客户端不应访问的类中。

请留意，客户端对一切这些服务类都具备传递性依赖。在静态言语中，对其中一个服务类源代码的更改将强迫客户端从新编译。此外，你可以构想经常使用此结构创立反向通道是如许容易。

咱们曾经看到了局部成功不齐全边界的三种简双方法。当然，还有很多其余方法。这三种战略仅作为示例提供。

这些方法中的每一种都有其自己的老本和收益。在特定的状况下，每种方法都是适宜的，作为一个最终齐全边界的代替打算。假设该边界从未成功，则每种方法都或者会遭到侵害。