BT

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

Eric Evans谈领域驱动设计、微服务与边界

| 作者 Jan Stenberg 关注 9 他的粉丝 ,译者 邵思华 关注 1 他的粉丝 发布于 2015年6月22日. 估计阅读时间: 3 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

在今年于伦敦举办的DDD Exchange大会的主题演讲中,Eric Evans表达了他对微服务的看法。尽管微服务这个词现在已经有点炒作的味道,但Evans相信微服务确实蕴含着巨大的价值,它为我们带来了或许是迄今为止最好的实现领域驱动设计(DDD)的环境。

对于Evans来说,良好设计最重要的关键因素是迭代。他也相信,微服务是继SOA之后第二次对实现正确的架构设计的尝试。这两者之间的一个主要区别在于:微服务非常强调隔离性,相比较而言,过去在尝试SOA的过程中经常使用数据库作为集成的手段。微服务允许自治的团队各自开发不同的服务,DevOps的发展则使服务能够独立地创建与部署,这就为我们提供了天然的边界,在开发过程中不必与其它服务纠缠在一起。他同时也相信,微服务中所用到的技术正在变得更为轻量级,并且耦合性更低。

微服务为DDD带来了真正的边界,而微服务社区所推崇的各种思想,例如不要共享,这正是我们希望在边界上下文中能够实现的能力。但Evans同时也提醒我们,如果缺乏一种高层次的设计视图和策略,那么仍有可能发生混乱的情况,大量的服务看起来就像老式的一体化、相互纠缠的系统。Evans强调,并不是每一个大型系统的设计都是良好的,他认为微服务能够在经过良好设计的服务与设计及实现很糟糕的服务之间创建一种隔离性。

在Evans看来,一个微服务的操作方式恰好能够生成一个良好的边界上下文,至少这是一个良好的起点,它在服务与上下文之间建立起了某种一对一的映射。随着服务开始逐渐小型化,并以某种非常特定的方式与其它小型服务进行协作与交互,那么这个边界上下文或许能够涵盖所有这些小型服务。不过,以他的经验来说,我们经常会设计出过于庞大的边界上下文。传统的一体化服务端应用总是会成为一个单一的上下文,这会造成这个上下文过于庞大。最后,他再次重审,应由具有这方面技能的人从一个更高的层次去发现系统中的领域与上下文,这一点对于应用的开发十分重要。

下一年度的DDD Exchange大会预定于2016年6月10日举办,现已开放注册。

查看英文原文Eric Evans on DDD, Microservices and Boundaries


感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT