领域驱动设计与微服务边界:从概念到实践
领域驱动设计基础概念
在不同的上下文中,术语可能具有不同的含义,这是正常的。我们只需在特定领域模型的有限上下文中达成对术语通用含义(通用语言)的共识即可。通过观察术语含义发生变化的边界,我们可以识别出上下文的边界。
在领域驱动设计(DDD)中,并非讨论领域模型时想到的所有术语都能成为相应通用语言的一部分。处于有限上下文中且对该上下文主要目的至关重要的概念,才是团队通用语言的一部分,其他的则应排除在外。这些核心概念可以从为有限上下文创建的待办事项集(JTBDs)中发现。例如,使用工作故事(Job Story)语法可以识别通用语言的关键术语,关键名词对应相关通用语言中的术语,我们推荐利用编写良好的工作故事中的关键名词来确定与通用语言相关的词汇术语。
上下文映射
DDD 不会用单一的领域模型来描述复杂系统,而是设计多个独立的模型,这些子域通常通过发布的接口描述进行通信。在大型系统中,各个领域的表示以及它们之间的协作方式被称为上下文映射,识别和描述这些协作的行为就是上下文映射。
DDD 在映射有限上下文时确定了几种主要的协作交互类型:
- 共享内核 :当两个领域基本独立开发,却意外地在各自领域的某个子集上重叠时就会出现共享内核。双方可能会就这个共享内核进行协作,其中可能包括共享代码、数据模型以及领域描述。然而,共享内核是一个有问题的模式,尤其是在微服务架构中。它需要两个独立团队高度协调,后续的任何修改也需要持续协调。如果在微服务架构中必须使用共享内核,建议指定一个团队作为主要所有者/管理者,其他团队作为贡献者。
- 上下游关系 <
超级会员免费看
订阅专栏 解锁全文
176万+

被折叠的 条评论
为什么被折叠?



