分享基于 REST 的企业集成经验

“如何替换大型遗留系统，是 IT 业界的一大难题”，ThoughtWorks 的首席咨询师 Brandon Byars ，在分享其在大型遗留替换项目中使用 RESTful 集成的经验时这样说道。

Brandon 认为对大多数这类项目来说， REST 都要比 HTTP 吸引人。它易于使用和理解，不需要大型框架。在架构方面，他坚信 REST 已经被证明是可伸缩的，并且适用于领域建模。他发现很多时候，针对 REST 的讨论都是关于一些小的细节，而不是对项目成功更加重要的部署和测试方案。

Brandon 的第一个建议是，在开发中使用逻辑环境来满足不同团队和角色的需要：

逻辑环境是一组适当隔离的相互关联的应用程序、服务和基础组件，可以满足业务和开发的需要。

接着，他描述了几种不同的技术，这些都是值得使用和为其维护环境的。而环境的版本控制是他坚决反对的，他认为这样会使系统严重地复杂化。

Brandon 的经验是，错误地定义数据边界，是架构师所犯的最昂贵的错误。一个常见的反模式是，将某个实体的所有信息都保存到单个数据存储中，并在需要的时候导出。他认为如果对主数据管理（MDM）认识肤浅就会支持这种方案。相反，他的解决方案是将各个团队的定义包装在一个边界上下文中。边界上下文是领域驱动开发中的概念，在边界上下文中，一个术语不管用于何处，都表示相同的含义。

每个业务单元对于相同的实体都有不同的模型，可以在它们的边界上下文中进行显式的翻译。

在应对分布式系统时，Brandon 建议将针对高级特性的用户故事分组成史诗，并用这些史诗来度量进展。这可以避免对进展产生错觉的情况。大多数故事完成意味着团队正处于交付过程中，但少量故事未完成则会妨碍特性的演示。

程序级别的度量使得史诗成为跟踪团队速率的首要标准，因为团队用户故事的速率会造成对进度的错觉。

Brandon 最后强调，尽管他支持使用 RESTful 服务的方案，相信它能简化开发，但 REST 还远不是银弹。

原文英文地址： Experiences from Enterprise Integration with REST