更具体地说，假设我有两个服务：
> CustomerService：包含我的Customers数据库表和关联的业务逻辑。
> OrderService：包含我的Orders表和逻辑。
现在如果我需要使用SQL语句加入Customers和Orders表？如果表格包含数百万条目，如果我必须通过使用SOAP / XML的网络发送数据，将导致不可接受的性能。以及如何执行JOIN？
做了一点研究，我发现了一些提出的解决方案：
> Use replication在需要时制作所需数据的本地副本。但是那么没有封装，那么使用SOA的重点在于什么呢？这是on StackOverflow，但没有明确的共识。
>设置一个封装所有数据库数据的Master Data Service。我想这会让怪物大小(每个存储过程基本上有一个API调用)，并且需要更新。对我来说这似乎与enterprise data bus概念有关。
如果您有任何意见，请告知我。
编辑：一年过去了，我对SOA的兴趣一直在减少，而概念的普及也在减少。如今，人们似乎想专注于RESTful服务。
在这种情况下，“服务”的定义主体之一是绝对拥有其负责的领域的数据以及该数据的操作。通过复制或任何其他机制复制数据可以减轻责任。您也可以复制业务规则，否则您最终会卷入需要更新的其他服务以更改内部规则的情况。
使用单一数据服务只是“不要做SOA”;如果您拥有管理所有数据的单一位置，则您没有独立的服务，您只需要一个服务。
相反，我建议使用第三个选项：使用组合将数据放在一起，避免数据库级的JOIN操作完全。
而不是考虑在数据库中将这两个值一起加入，考虑如何将它们组合在一起：
当您为客户呈现HTML页面时，您可以从多个服务提供HTML，并将它们彼此视觉化：客户详细信息来自客户服务，订单服务的订单详细信息。
同样的发票电子邮件：从多个服务组合数据可视化，而不需要数据库内连接。
这有两个优点：一，你不需要加入数据库，甚至需要将数据存储在同一类型的数据库中。现在每个服务都可以使用任何数据存储最适合他们的需要。
二，你可以更容易地改变你的应用程序的外部。如果您有小的可组合部件，您可以轻松地以新的方式添加重新排列零件。