边界组件
如何让服务、技术和其它交叉问题（比如安全、记录等）等业务方面的问题可以按自己的步调变更而不产生相互的依赖性？ 最简单的（或许过分简单了）办法是不要做任何具体的变动。比如，直接把一部分逻辑当作Web服务。这对技术提供商的在线业务来说是很常见的，比如Microsoft （WCF）和 Sun （JAX-WS）提供的教程。然而，由于契约操作与业务逻辑实现直接纠缠在了一起，这给代码维护带来了极大的不便——比如，如果要支持场景1，用这种方法来替换技术可能就会非常困难。 我们可以通过在复制服务上替换新技术来解决前面的在当前服务中替换技术的问题，这种方法也叫“自我克隆（own and clone）”。
关注点分离（SoC）在面向对象的设计中是一个为人熟知的概念。其背后的基本原则是单一责任原则（The Single Responsibility Principle），或简称为SRP。SRP认为要改变一个类只能有唯一的原因，这个原因就是责任（responsibility）。我们可以在SOA中应用同一原则，把业务逻辑看作是一个责任，把其它的问题看作是另一个责任，这样我们就得到以下模式： 附加边界组件（Add Edge Component（s）），用以实现服务并提高灵活性、分离业务逻辑与其它问题（比如契约、协议、终端技术和其它交叉问题）。
从某种意义来说，边界组件模式可以为SOA提供外观（fa？ade）、代理、和AOP模式。最好的办法是进一步扩展单一责任原则，并且注意边界组件实际上是一个组件，不能把它对应于整个类型的类。比如，你可以应用管道和过滤架构类型，把多个类/组件连接到一起，各个类/组件处理特定的问题，以此来创建传入或传出的流程。
虽然从一开始就在边界组件和服务之间定义一个内部契约很有吸引力，但是实际上没有理由这么做，除非你必须支持多个外部契约（虽然实现与消费者一对一的契约非常麻烦——见PTP Integration反模式）。如果服务进展并且创建了新的契约版本，像场景1中像添加新技术，那么在需要支持外部老版本的契约时你可能需要添加内部契约。