虽然我们正在推断有界上下文，但域专家应该或必须理解“有界上下文”，“问题空间”，“子域”等术语。甚至，什么构成有界上下文或子域？
例如，在创建Clinic系统域时，子域将是预约系统，患者管理。所以问题是我应该告诉我的领域专家我是一名开发人员，我将问题分成更小的子域，边界环境（预约系统）将构成患者和计费环境。这里的“背景图”是等等。
基本上，如果域专家关心我是遵循DDD方法还是CRUD开发方法，或者换句话说，应该在无处不在的语言中包含术语“有界上下文”，“子域”等吗？
答案 0 :(得分：3)
领域专家应该了解问题空间，但他们不应该知道解决方案空间。
域和子域描述问题空间。我想不出一种方法可以与专家讨论业务的不同部分，而不会给这些部分赋予通用名称。子域名是我们在DDD中的词，为什么不使用它？子域名通常也与公司中的不同团队或部门相匹配，这肯定会在与专家的讨论中出现。
在
这样的句子中
此团队处理发票[...]
好的，现在我们完成了购买[...]，让我们继续购买[...]
此功能是否属于约会[...]？
你需要一些概念来填补空白。
相反，有界上下文是在解决方案领域。我可以理解为什么你会以这些条款与QA人员或CTO谈话，而不是商业专家。它与提及数据库，Web服务器或消息队列相同。如果他们感到好奇，专家会想知道更多，但你不应该根据他们的理解来理解它。答案 1 :(得分：2)
“DDD语言”是DDD书中的无处不在的语言，而不是开发人员的元数据术语。
埃里克埃文斯非常清楚这个话题。第2章，“无所不在的语言”：领域专家应该反对那些尴尬的术语或结构 或不足以传达领域理解;开发者应该关注 因为模糊或不一致会使设计绊倒。
查看同一章中“One team，one language”段落中的图表，了解UL是什么。它包含“有界上下文的名称”（即您的示例中为"Appointment system"和"Patient management"），但不包括术语"Bounded Context"。
领域专家与其脑细胞有其他重要的事情，而不是学习我们的行话。事实上，她的工作非常复杂，你正在开发一个自动化系统。
怜悯地说"Appointment system"代替"sub-domain"，或"In <specific case> the Order moves from Appointment system to Patient management department"代替"This Order is an interface point on a cross-domain boundary"。这对你们两个都有帮助。
答案 2 :(得分：1)
我认为你应该与领域专家分享有界的上下文和子域名。 DDD背后的想法是共享和认可的知识。
但是，我不认为你必须使用精确的术语'有界上下文'和'子域'。您可以使用这些，这些可能是无处不在的语言 - 如果有用的话。我认为这是一个关于你的领域专家如何理解这些术语的问题，如果你应该使用不同的术语来让他们更容易理解。
答案 3 :(得分：1)
根据我的理解，泛在语言（UL）是一套非常强大的语言工具，可以与问题领域专家进行有效协作。我会将UL映像为开发人员和领域专家之间的语言代理或翻译服务。因此，UL不应包含任何与编程相关的技术术语，而应包含域概念。
当开发人员考虑域概念时给你一个例子：
在处理
PatientRequiresAppointment模块中的Appointment命令时，AppointmentDomainService应该检查Patient的SSN-id是否有效且有已根据收到的DTO属性付款。
如果我们尝试将其翻译为更适合域名的语言：
当检查患者的社会保险号并确认其有效性时，预约条目得到确认。
现在这个版本是用技术术语清除的，但它可能会引入两个未知的动词。检查和确认这些应与领域专家协调。通过这种方式，您的域的UL将不断重新变形，并且当您注意到您使用某种重载术语时（例如：第一个示例中的AppointmentDomainService），将会引入或删除新的动词/名词。
到目前为止，您可以了解口语UL的重要性，接下来要回答的是：
DDD的一个关键概念是协作！所以，是的，您应该与您的领域专家密切合作，甚至教他们所谓的有界背景的见解。我相信从长远来看，这对团队来说是一个附加值，因为他们还将了解给定上下文的界限，并且您还将了解问题域的这个区域在他们的业务中是如何工作的。
我将尝试解释通过在项目的重点部分应用DDD所获得的一些成功。