BT

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

领域驱动设计与微服务

| 作者 Mikael Zandin 关注 0 他的粉丝 ,译者 谢丽 关注 9 他的粉丝 发布于 2016年4月26日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在QCon伦敦2016大会上,《领域驱动设计》一书的作者Eric Evans提出,使用领域驱动设计(DDD)概念减少微服务环境中通用语言的复杂性。

团队使用不同的通用语言给管理微服务环境带来了特殊的问题。团队会开发自己的通用语言,并在自己的领域范围内赋予它们意义。然而,这些通用语言的概念在团队的语境之外并未保持一致。一个团队对“客户”的定义可能与另一个团队的定义存在明显的差别,导致了不必要的复杂性。此外,每一种语言都会在各自的团队内发展演变,几乎可以确定早晚会出现迥然不同的定义。

Evans谈到,团队会犯编码错误及误解需求,导致错误和糟糕的代码。虽然这时有发生,但最坏的情况是这些错误渗透到了其他不相关的微服务中。Evans区分了他所谓的“小泥球”和“大泥球”,前者是指问题包含在一个微服务中,后者是指一个微服务中的问题扩散到整个环境。

Evans介绍了三种可以帮助管理微服务环境的DDD工具:上下文映射、“防腐层(anti-corruption layer,ACL)”和“交流语境(interchange context)”。上下文映射代表微服务间的通信路径,暗含了微服务团队之间的适当交互。一旦这种分析成熟,团队就可以选择依赖不同团队的领域语言,在这种情况下,ACL可能就有意义了。ACL的职责是将外部概念翻译成内部模型,从而实现领域间的松耦合。在两个团队需要更多合作的情况下,交流语境可能更有意义。交流语境比ACL更完善,它提供了一个层,供两个团队讨论词汇意思,并来回翻译微服务语言。

将代码从单体应用移植到一个微服务系统会把上下文复杂性从代码转移到微服务之间的空间。微服务之间的交互现在包含了逻辑,这些逻辑以前存在于易于阅读和调试的代码中。这种新的上下文必须妥善管理,否则整个系统就会发展成为Evans所说的“大泥球”。

Evans建议,将每个微服务设计成一个DDD有界上下文。这为系统内的微服务提供了一个逻辑边界,无论是功能,还是通用语言。每个独立的团队负责一个逻辑上定义好的系统切片。最终,团队开发出的代码会更易于理解和维护。

查看英文原文:Domain-Driven Design and Microservices

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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