“如何替换大型遗留系统,是 IT 业界的一大难题”,ThoughtWorks 的首席咨询师 Brandon Byars ,在分享其在大型遗留替换项目中使用 RESTful 集成的经验时这样说道。
Brandon 认为对大多数这类项目来说, REST 都要比 HTTP 吸引人。它易于使用和理解,不需要大型框架。在架构方面,他坚信 REST 已经被证明是可伸缩的,并且适用于领域建模。他发现很多时候,针对 REST 的讨论都是关于一些小的细节,而不是对项目成功更加重要的部署和测试方案。
Brandon 的第一个建议是,在开发中使用逻辑环境来满足不同团队和角色的需要:
逻辑环境是一组适当隔离的相互关联的应用程序、服务和基础组件,可以满足业务和开发的需要。
接着,他描述了几种不同的技术,这些都是值得使用和为其维护环境的。而环境的版本控制是他坚决反对的,他认为这样会使系统严重地复杂化。
Brandon 的经验是,错误地定义数据边界,是架构师所犯的最昂贵的错误。一个常见的反模式是,将某个实体的所有信息都保存到单个数据存储中,并在需要的时候导出。他认为如果对主数据管理(MDM)认识肤浅就会支持这种方案。相反,他的解决方案是将各个团队的定义包装在一个边界上下文中。边界上下文是领域驱动开发中的概念,在边界上下文中,一个术语不管用于何处,都表示相同的含义。
每个业务单元对于相同的实体都有不同的模型,可以在它们的边界上下文中进行显式的翻译。
在应对分布式系统时,Brandon 建议将针对高级特性的用户故事分组成史诗,并用这些史诗来度量进展。这可以避免对进展产生错觉的情况。大多数故事完成意味着团队正处于交付过程中,但少量故事未完成则会妨碍特性的演示。
程序级别的度量使得史诗成为跟踪团队速率的首要标准,因为团队用户故事的速率会造成对进度的错觉。
Brandon 最后强调,尽管他支持使用 RESTful 服务的方案,相信它能简化开发,但 REST 还远不是银弹。
评论