SOA专题
使用REST实现企业集成
大意译自Enterprise Integration Using REST
传统大型系统的替代是很难的。大型遗留的更换是在整个IT行业最困难的工作。
许多网上讨论的REST只是涉及有关内容类型和超媒体作为应用状态（ HATEOAS ）引擎等有关细节，但没有什么有关REST做大型集成项目的建议或工程和实践。
布兰登拜尔斯，这位ThoughtWorks的首席顾问认为：REST over HTTP的是一个有吸引力的选择很多项目，它是易于使用和理解，并且不需要大的框架。在结构上，他认为，REST已被证明是可扩展性以及与领域建模和谐相处。
一个合乎逻辑的环境是需要将一套相互关联的应用程序，服务和满足业务或发展需要的基础设施所需要的组件这三者进行适当分离。
在一个零售项目，订单录入小组的开发人员可能需要产品目录和客户管理的服务，而不是用于仓库管理的服务。但开发者和的ＱＡ需要在性能和可用性上隔离。在极端情况下，同一VM下的不同的开发人员可能有不同的逻辑环境。在这种情况下，隔离可以通过环境配置的端口和数据库名称等方法来完成。如下
版本控制的问题
基于逻辑环境的定义一个重要的推论是凝聚的概念 - 每个环境应该有一个给定服务的一个实例。不幸的是，在大型项目中，每个团队都是以不同的步伐前行，很容易碰上通常的编译时出现经典钻石依赖问题：
定义不清的数据边界是一个架构师范的最昂贵错误，一个常见的??反模式是存储实体在单一的数据存储，并根据需要导出所有的信息，这个策略是因为被主数据管理（MDM）肤浅的误解导致的。解决办法是将每个开发团队限定在一个有界上下文中的定义，这是领域驱动设计DDD概念。
每个业务团队对一个共同的实体都有不同的模型，分属于不同的上下文，可以在他们之间使用显式转换。
下图是一个传统基于主数据库目录的集中开发模式，导致多个开发团队无法在一个分离的边界下各自工作：
下图显示引入有界上下文以后，通过事件驱动如何实现各个team间的协调：
这个例子示出了四种不同的有界上下文(称为不同篇章epics)，一个NewProduct事件以一种常见的RESTful方法被传播。当创建一个新的产品后，产品的服务将这个新产品作为一个事件，在端点发送，消费者从这个服务端点获得事件，获得事件的方式像/notifications?since=2013-10-01.
另外，可以将一个服务端点看成是一个故事的上下文，一个大型的服务可能要由不同队伍来完成，将用户故事作为实施大型SOA的第一级最重要的线索来看待，每一个参与的团队都有自己的篇章epic。
创建客户的篇章也许包括订单条目和账单团队来辅助客户管理团队实现,他们每一个都有独立的面向服务和应用规范的故事，假设其中的服务所使用的由单独的团队开发的用户界面，我们未必能够展示我们的劳动成果的业务，直到我们已经完成了整个系统的流程。
传统的软件看板kanban方法试图在故事层面来限制正在进行中工作。重新调整每个古树中篇章的的数量。