大量的出版物都在描述 SOA 实现的设计，但却对接口（契约）设计鲜有关注，这让人不由得产生一种“实现的设计更重要而且更值得关注”的感觉。对此的一个常见理由是契约会随着时间改变，预先把过多的时间花在它们的定义上跟敏捷开发方法相抵触。
Steve Jones 在他最近的贴子里对这一普遍误解提出了异议，说道：
在我看来，这种看法就像那种不愿意写文档的伪敏捷人士，他们根本就是狗屁不通，而不是因为他们已经开发出了具备自描述能力的质量极高的组件。这基本上就是在说任何人都要等到系统可运行了之后你才能知道它的功能。这等于让需求改变适应实现。我现在并不是说需求不能改变，也不是鼓吹瀑布模型，而想说明 SOA 编程中的时间分配问题：在确定规格说明和设计过程中，大部分时间应该花在服务间的契约和交互上，至于关注如何设计这些服务满足契约，则可以少花些时间。
为什么契约是 SOA 实现中的最重要部分，Steve 列举了以下原因：
- 其他组件依赖的是契约而不是设计。因其错误而导致的成本跟提供者的数量成指数关系。一旦契约正确就位，那么人们就可以并行开发，这可以大大加速交付时间，减少风险。
- 测试是围绕契约而不是设计进行的。契约是正式的规格说明，设计必须满足它，而且各种形式的测试也都应该使用它。
- 设计可以在契约的边界内悄悄地改变。
契约的重要性这一概念并不是新鲜事物。按照 Dimuthu Leelarathne 的说法：
如果你没有首先设计服务间的契约，服务间复杂的集成问题就会出现。
实际上，创建好的服务契约并不是件易事，要求很好地理解契约核心业务。虽然已有一些服务接口设计的公认方法，但是更多的时候它还是艺术而非科学。结果，开发者和软件厂商都典型地把注意力放在了他们受到的培训（和要卖的东西）上——服务实现的设计和编码。在 Steve 看来：
……IT 的重点……太少地放在了确保外部接口至少在一段时间内保持正确的上面。契约可以演变，我有意地使用了这个术语，但大多数时候，旧的契约在人们迁移到新版本的过程中还要被支持。这意味着契约比设计拥有的生命跨度要长得多……契约是大事，设计则微不足道。
随着我们继续提倡将 SOA 用于业务/IT 对齐，与业务需求对齐的服务契约的作用会越来越明显。
查看英文原文： SOA Design: Is it about Contracts or Service Implementation?
评论