Architecture 有界语境与领域专家的参与

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

例如，在创建门诊系统域时，子域将是预约系统、患者管理。所以问题是，我是否应该告诉我的领域专家，我是一名开发人员，我将问题划分为更小的子领域，边界上下文（预约系统）将构成患者和账单上下文。这里的“背景地图”都是废话

---

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

我认为您应该与领域专家共享有界上下文和子域。DDD背后的理念是共享和一致的知识

然而，我认为您不必使用精确的术语“有界上下文”和“子域”。你可以使用这些，这些可以是普遍存在的语言——如果有用的话。我认为这是一个问题，你的领域专家对这些术语的理解程度如何，你是否应该使用不同的术语使它们易于理解。

在我看来，无处不在的语言（UL）是一套非常强大的语言工具，可以有效地与问题领域专家协作。我会把UL想象成开发者和领域专家之间的语言代理或翻译服务。因此，UL不应包含任何与编程相关的技术术语，而应包含领域概念

给您一个开发人员思考域概念的示例：

在

预约

模块中处理命令

patientsrequiresappoint

时，

AppointmentDomainService

应根据传入的DTO属性检查

患者

的SSN id是否有效并已支付费用

如果我们尝试将其转换为更为领域友好的语言：

当检查患者的社会保险号码并确认其有效性时，预约条目将得到确认

现在这个版本不再使用技术术语，但它可能会引入两个未知动词。检查和确认应与领域专家协调。通过这种方式，您的域的UL将不断被重塑，并将引入或删除新的动词/名词，例如，当您注意到您使用了某种重载术语时（例如：第一个示例中的AppointmentDomainService）

现在你可以了解口语UL的重要性了，接下来要回答的是：

您是否应该与您的领域专家一起使用DDD术语？ DDD的关键概念之一是协作！因此，是的，您应该与您的领域专家密切合作，甚至教他们了解所谓的有界上下文。我相信，从长远来看，这对团队来说是一个附加值，因为他们还将了解给定环境的边界是什么，并且您还将了解问题领域在他们的业务中是如何工作的

结语：DDD可能为您的团队带来的其他一些价值观 我将尝试解释我在项目的重点部分应用DDD所取得的一些成功

• 清晰而精确的上下文边界：在您的团队流程中应用上述各节中的内容可能会产生干净而纯粹的域模型，将重点放在具有严格定义的边界的实际域上下文上，以帮助为给定的业务问题带来有重点的解决方案！一般来说，这可能意味着干净、纯粹的代码旨在实现更简单的测试，这可能会带来更少的bug和更快的交付时间。这份名单可以无限期地延续下去
• 敏捷：DDD给我带来的最大好处之一就是学习如何更加敏捷。例如，在这种情况下的敏捷性可能意味着，您可以学习在建模业务问题时如何谨慎地进行平衡，您可以通过与领域专家密切合作来迭代地细化业务问题。我还学会了如何通过不断提供新特性来变得更加敏捷。这可能意味着您还可以学习新的方法，在与您的业务合作伙伴签订合同时，通过让他们相信这些附加值来提高敏捷性

“DDD语言”是DDD书籍中无处不在的语言，而不是开发人员的元数据行话

埃里克·埃文斯对这个话题非常清楚。第2章，第2段“胡言乱语”：

领域专家应该反对令人尴尬的术语或结构 或不足以传达领域理解；开发者应该关注 不明确或不一致将导致设计失败

查看同一章中“一个团队，一种语言”段落中的图表，了解什么是UL。它包括“有界上下文的名称”（即，在您的示例中为

“预约系统”和
“患者管理”
），但不包括术语
“有界上下文”

领域专家除了学习我们的术语外，还有其他重要的事情要做。事实上，她的工作是如此复杂，以至于你正在开发一个自动化系统

发发慈悲吧，说
“预约系统”
而不是
“子域”
，或者说
“在从预约系统移动到患者管理部门的订单中”
而不是
“此订单是跨域边界上的接口点”
。这对你们两个都有帮助。
领域专家应该知道问题空间，但他们不必知道解决方案空间

域和子域描述问题空间。我想不出一个方法来与专家讨论一个系统的不同部分