微服务概念和电商微服务设计思想（2）

最新推荐文章于 2024-08-05 08:39:49 发布

码事通

最新推荐文章于 2024-08-05 08:39:49 发布

阅读量111

点赞数

分类专栏：微服务文章标签：微服务 java 数据库学习后端分布式

本文链接：https://blog.csdn.net/m0_64355285/article/details/132635323

版权

本文详细解释了领域驱动设计中问题域和解决方案域的区别，重点阐述了核心领域、子领域与限界上下文的关系，以及限界上下文在划分业务、工作和技术边界，降低系统复杂度中的作用。作者强调了限界上下文作为抽象单元而非固定设计单元的重要性。

摘要由CSDN通过智能技术生成

问题域与解决方案域

领域驱动设计的整个过程，其实就是从问题域到解决方案域的过程。问题域属于需求分析阶段，重点是明确这个系统要解决什么问题，能够提供什么价值，也就是关注系统的 What 与Why。解决方案域属于系统设计阶段，针对识别出来的问题域，寻求合理的解决方案，也就是关注系统的How。在领域驱动设计中，核心领域（Core Domain）与子领域（Sub Domain）属于问题域的范畴，限界上下文（Bounded Context）则属于解决方案域的范畴，它们之间的关系如图：

很多人总是困惑于核心领域/子领域与限界上下文之间的关系

一对一、一对多，或者多对多？然而就上图所示，由于二者出现在不同阶段，关注的重心也不尽相同，因此准确地说，它们之间并没有所谓的映射关系。前者关注于系统的价值与功能，因而对它们的识别，只限于从业务上对它们的分解。之所以要区分核心领域与子领域，不过是为后续的解决方案域提供实现成本的考量。对于核心领域，我们应付出更多的开发成本，组建更好的团队为其建立稳定正确的领域模型；至于子领域，就可以降低设计与开发要求，甚至可以引入外包团队对其进行开发，或者购买提供通用功能的组件或服务。

从问题域到解决方案域，实际上就是从需求分析到设计的过程，也是我们逐步识别限界上下文的过程。限界上下文是解决方案域的架构基石。一些开发人员在接触领域驱动设计时，常常会疑惑限界上下文究竟是什么？他们往往会结合自身的开发经验，想要将限界上下文视为模块、组件、包或服务。这实际违背了Eric Evans引入限界上下文的初衷。在从问题域推演至解决方案域时，限界上下文仅仅是一种业务边界的划分，在这个时候，根本就不应该考虑它究竟是模块、组件、包还是服务，因为这会导致技术决策对领域分析的干扰。只有在初步确定了限界上下文之后，进入实现阶段时，才开始考虑它究竟该映射为模块、组件、包还是服务，这一决策会直接影响整个系统的架构。