architecture - 限界上下文和领域专家的参与

Question

当我们推导限界上下文时，领域专家是否应该或必须理解“限界上下文”、“问题空间”、“子域”等术语。甚至，什么构成了有界上下文或子域？

例如，在创建诊所系统域时，子域将是预约系统、患者管理。所以问题是我是否应该告诉我的领域专家我是一名开发人员并且我将问题划分为更小的子域并且边界上下文(预约系统)将构成患者和计费上下文。和这里的“上下文映射”是废话。

本质上，领域专家是否应该关心我是在遵循 DDD 方法还是 CRUD 开发方法，或者换句话说，术语“限界上下文”、“子域”等是否应该包含在通用语言中？

Answer 1

领域专家应该了解问题空间，但他们不应该必须了解解决方案空间。

域和子域描述了问题空间。如果不给这些部分一个通用名称，我想不出一种方法来与专家讨论业务的不同部分。子域是 DDD 中的词，为什么不使用它呢？子域通常也与公司中的不同团队或部门相匹配，这肯定是在与专家讨论时会出现的问题。

像这样的句子

• This team handles the Invoicing [...]

• Okay, now we're done with the Purchase [...], let's move on to the Stock [...]

• Doesn't this feature rather belong to the Appointment [...] ?

你需要一些概念来填补空白。

相比之下，限界上下文位于解决方案空间中。我明白为什么您会用这些术语与 QA 人员或 CTO 交谈，而不是与业务专家交谈。这与提到数据库、Web 服务器或消息队列一样。如果专家很好奇，他们会想知道更多，但您不应该将谈话建立在他们理解的基础上。