我正在努力将我们的企业技术范式转变为敏捷开发。这是一个艰难的过程，但我们快到了！:)
我们有用于数据库管理的遗留系统（以前是 Access，现在移植到 .NET 和 MS SQL），我们正在为我们的未来愿景开发一个框架。我们希望尽可能多地迁移到网络。但我们希望将当前系统与“即将推出”的系统集成。我们不会重叠任务和功能。
我的愿景是将我们用户的所有联系信息移动到不同的数据库，将这些“配置文件”链接回 MS SQL 以获取他们的历史和会计信息。我们会将所有会计系统保留在桌面应用程序上，但我们将添加更多功能，这些功能将严重依赖于 Web，尤其是 Ruby on Rails。
我想问题是：为什么是 ESB？有没有一种方法可以创建 SOA，而无需对复杂的 ESB 系统进行狂热的操作。无论如何，整个想法是亲吻。是否可以以允许桌面/Web/移动作为接口的方式创建 SOA，将功能保留在业务逻辑上（当然，某些功能必须在接口上实现，但要保持在最低限度）。ESB 甚至符合敏捷哲学吗？我阅读和研究它们的次数越多，我就越不这么认为！：/
感谢您的输入！如果您需要我澄清，请提出几个问题，我会尽力做到这一点！:)
一旦框架/基础设施到位，ESB 就非常适合敏捷。你会发现可以分块创建新系统，新的部分和旧的系统并行运行一段时间，然后逐渐关闭系统的旧部分，直到只剩下新的系统，没有人会永远知道区别
一个基本的 SOA 只定义服务而不是应用程序；ESB 管理通道中的服务以隐藏端点，使升级和替换更加“敏捷”
我很快就学会了回避“ESB”这个词，因为它非常过载并且对不同的人意味着不同的东西（有时对同一个人来说不同的东西:-)）
当然，关键是问问自己你真正需要什么。
将您的数据库包装为服务可能是一个明智的选择，尤其是如果您有多个客户端来处理这些数据；您将不得不花费大量时间来考虑您的合同和范围，但敏捷可以在这里提供很大帮助。
现在的问题是如何调用这些服务，我认为您需要权衡客户端和服务更改的可能性以及您的系统将如何发展。
服务总线有助于从其客户端（可以是其他服务）屏蔽服务，并且这种“屏蔽”可以中继到位置、协议、格式、代码等。某些形式的服务总线还可以维护行程（需要打电话，什么时候），但我通常不喜欢这个主意。
所以-我认为，您首先需要问自己的问题是您需要从什么开始以及您希望进行多少前期投资（并且可以证明是合理的）
例如，如果最初您对更点对点的方法感到满意，您的客户可以直接调用该服务；在稍后阶段，随着服务的发展，您可以引入“中间人”来代理请求和响应（是的 - 如果您愿意，您可以将其称为 ESB）。
或者，您可以从一个基本的“中间人”开始，这样客户就不会直接调用服务，而只是拥有您需要的功能，并以需求形式扩展它的功能；它很可能从一个简单的转发机器开始。
理想情况下，您将构建在具有许多内置功能的产品之上；如果您在 MS 堆栈上，BizTalk Server 是一个很好的匹配（但有它的学习曲线）
所以 - 如果这不是一个非常具体的答案，请道歉 - 但我想我的主要观点是“ESB”不一定是矫枉过正，它只是归结为你希望在第一天拥有的东西，以及敏捷（和 SOA ) 绝对有帮助，因为它允许你逐渐进化，而不是像大爆炸一样。
（如果以上任何内容完全是胡说八道，或者只是有点不清楚，那是因为家里有一个新出生的孩子睡眠不足！道歉:-)）
整个迁移是让我接触到 ESB 的原因……但是 ESB 的整个想法似乎很复杂，无法解决涉及大约 30,000 个配置文件的问题！我们正处于指数级增长的边缘（达到几百万个配置文件），也许开始一条新的道路是最好的。将位于 MySQL DB 上的条目链接到存储在 MS SQL DB 上的数据有多容易？我显然不想要复式输入，但是可能有比“整个” ESB 更敏捷的方式......我确实理解带有 ESB 的 SOA 在升级和替换方面可能非常敏捷，但它会是吗？矫枉过正？:)