演化式 SOA

SOA 可以用敏捷方法实现吗？

我不会过多地深入 SOA 的混乱世界（面向服务的模糊性），但我经常收到这个问题（以某种形式），值得我发表一下看法。

当我第一次接触敏捷软件开发（以极限编程的形式）时，对我来说最令人不安的是它对软件设计的方法。像许多人一样，我已经习惯了在编程之前设计软件的概念，而 XP 似乎鼓励几乎有意地拥抱设计无知。在 2000 年，我被邀请在第一个敏捷/XP 大会上发表闭幕主题演讲，为了整理我的思路，我最终写了设计已死吗？ - 一篇探讨敏捷世界中设计命运的文章。

我仍然对那篇文章感到非常自豪，我认为它今天仍然值得一读 - 但对于这篇博客文章，我将总结一下。我谈到了两种驱动软件设计的方法：计划和演化。计划设计在一个阶段中制定软件的设计，并在之后构建（编程）它。在这种情况下，一旦你开始构建，改变设计就很难了。演化设计假设即使你已经完成了大量的编程，也要定期更改设计。我得出结论，XP 的实践提供了一种纪律严明的演化设计方法，从而使其比人们意识到的更加实用。这种变化并没有消除软件设计（它并没有死），而是显著地改变了我们思考设计的方式。

在 SOA 上下文中，计划设计的论据是，我们正在构建相互连接、松散耦合的系统网络。在这种情况下，每个系统都将它的服务作为发布接口提供给整个企业。发布接口很难更改，因此你需要计划设计来使它们正确，这样你就不用更改它们。计划设计也是对人们在大多数组织中看到的混乱的系统互连的反应。这种混乱是设计不良的结果，因此人们认为更好的计划设计将防止这种情况在未来发生。

演化设计是敏捷方法的一个重要方面。敏捷方法的关键基础之一是希望处理，甚至欢迎变化。计划设计假设变化是困难的，因此试图预测变化发生的地方。如果变化发生在预测的范围内，那么它很容易，但如果它超出了这些范围，你就会很倒霉。敏捷思维假设不可预测的变化是不可避免的，并试图以受控的方式实现它。

因此，当我查看 SOA 或任何其他设计上下文时，我提出的基本问题是“变化是否可预测？”只有当变化可预测时，计划设计方法才是有效的。我的感觉是，如果在一个应用程序的上下文中可预测性很困难，那么在整个企业范围内它就更加困难。如果我们在不可预测的上下文中使用计划设计，我们会发现，无论计划多么好，它们都会被不可预测的变化所破坏，导致我们目前遇到的同样的混乱。然而，通常情况下，混乱更糟，因为在计划设计中存在大量的沉没成本，这很容易降低 SOA 工作旨在产生的业务价值，特别是如果上市时间很重要。

因此，我认为我们必须咬紧牙关，想办法在这种松散连接的上下文中进行演化设计。毕竟，松散耦合的全部意义在于使变化更容易。这的核心是考虑合同的变化，以及诸如消费者驱动合同之类的想法。

这个方向导致了像 Jim Webber 的游击队 SOA这样的概念。这通过产生业务价值来构建 SOA，并使用小步骤。由于产生业务价值是重点，因此这提供了一条产生更高投资回报率的途径。这绝对是我们客户所欣赏的一种方法。

演化设计可以扩展到 SOA 的规模吗？在我看来，我们有一个比大型 SOA 工作更大的规模的生存证明 - 互联网本身。互联网建立在非常松散的耦合和大量不可预测的变化之上。从很多方面来说，它是一个混乱 - 但它是一个有效的混乱，每天为很多人提供真正的价值。