BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 姚琪琳 关注 0 他的粉丝 发布于 2013年12月3日. 估计阅读时间: 2 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

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

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

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

好像没说什么东西。。 by lone flying

。。

这个翻译让人摸不着头脑 by Json OY

这个翻译让人摸不着头脑

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT