SOA 的目标是以服务作为构建企业应用的“积木块”，使整个企业敏捷起来，而敏捷软件开发则是通过引入一些最佳实践来增加沟通与反馈，以达到同样的目的。InfoQ 贴出这篇文章的目的是归纳在这一主题上的观点，以便社区进一步交流与沟通，即 SOA 和敏捷：是朋友？还是敌人？。
这篇文章给出了对上述两种技术正、反两方面的观点，读者们已经开始讨论，并表述各自的观点。
该文建议说，尽管 SOA 是一种架构，而敏捷是一种开发方法论，但它们并非是完全正交的。
一方面，敏捷方法（例如 XP）直接关注设计，不是特别同意预先做大量设计 (BDUF) 的观点。另一方面，大多数 SOA 团队主要是围绕构建一系列服务而组成的功能性团队。SOA 本质上鼓励有特性的团队结构和团队间的沟通方式，而这两点又都属于方法论的范畴。
根据这种评判原则，该文提出了它们的主要重合点——即二者都关注“使业务敏捷起来”，随后深入讨论并提出了这两种实现方法的三个主要交叉点：
- SOA 鼓励架构设计在前，而敏捷对这种称为“BDUF”的方法持相反观点。
- SOA 鼓励按功能线索来划分团队，而敏捷倾向于以交叉功能式组建团队。
- SOA 中，服务一旦建立起来，SOA 就不再对服务的变化做出相关的反馈，而敏捷则强调及时反馈，无论是技术层面，还是人的层面。
关于这个主题已经引起了广泛的讨论。主要的讨论思路已经在这个贴子中提及。所以接下来的引证直接来源于这一主线。至今，大多评论者都未发现 SOA 和敏捷之间的交叉，当然，有一部分人同时支持这两种方法。
Frank Grossman 认为，在企业中，根据 SOA 的本性，很多的敏捷实践（如代码共享）可能被改变：
代码共享制也上升了一个层面。在项目层面的敏捷实践中，整体团队拥有所有的代码。而 SOA 层面的敏捷实践中，设计规约的交叉功能团队拥有 XML 软件层所有权。事实上，可以认为它是 SOA 所有者（就像是 Scrum 中的产品所有者），代表整个企业的目标。这个 SOA 所有者负责维护 SOA 列表, 并通过 XML 软件层的一系列的迭代，来指导一个或多个“XML 开发团队”。这个 SOA 列表包括已划分了优先级且能满足市场要求的业务需求。
而 Howard Deiner 认为，不应该草率地分解 SOA：
根据我的经验，一次就正确地分解一个 SOA 是非常困难的。在一个商业性企业中，存在很多不确定因素。在那样的环境下，大多数情况是在最终把业务流程实现成一组服务之后，却发现这些服务并不是我们真正想要的基本业务组件。所以，如果我们希望 SOA 一开始就成功，就必须理解并承认使用敏捷技术的重要性，敏捷技术使我们可以设计、构建、测试并验证每个 SOA 组件的可用性。当然，这也需要一点 BDUF，但边界可能要宽松一些，以便在后续的迭代中做架构刺探（architectural spike）时，各组件边界间的空隙足以将代码形成解决方案。
这是一个目前关于软件开发社区中两大阵营交锋的有趣话题。
阅读全文并参与评论： SOA and Agile: 是朋友？还是敌人？
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论