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