《领域驱动设计》：8.1.3 深层模型的建立

实际工作中出现的场景是，产品经理和领域专家沟通后，未与研发达成“通用语言”的同步，导致对同一“模型”的理解偏差，（这边的“模型”，不仅指数据的抽象，更多指代业务的抽象）。

Q1：具体工作流中，产品负责人和研发之间应该如何指定ubiquitous language？

A1：

在具体的工作流中，产品负责人和研发团队都应该参与到 Ubiquitous Language 的制定过程中来，以确保语言能够充分反映业务需求，并且得到开发团队的认可。

以下是一个可能的指导步骤，用于产品负责人和研发团队合作制定 Ubiquitous Language：

1. 确定业务领域：首先需要确定系统所涉及的整个业务范围，列出所有的相关业务领域。

2. 鉴定业务专家：针对每个业务领域，需要找到相关的业务专家，他们可以帮助定义业务术语并提供相应的业务规则。

3. 制定业务术语表：在每个业务领域中，与业务专家一起制定包含所有重要业务术语的术语表。为每个术语提供说明，确保术语的含义得到准确理解。

4. 识别上下文边界：在整个业务流程中，应该标识出各种上下文边界（Context Boundaries），明确不同业务领域之间的分隔点。

5. 定义限界上下文模型：基于上下文边界，划分出每个业务领域的限界上下文（Bounded Context），并在每个上下文中定义相应的领域模型。

6. 交流和反馈：所有团队成员都需要参与到 Ubiquitous Language 的制定过程中，进行交流和反馈，确保语言得到适当的修正和完善。同时也需不断地根据实际业务情况进行调整和修改。

通过以上步骤的指定，产品负责人和研发团队可以共同确定 Ubiquitous Language，确保开发代码和业务术语是一致的。这样可以避免团队成员之间出现沟通障碍，加快项目的开发进度，提高系统性能及可靠性。

 

Q2：识别到新的ubiquitous language之后，是否有必要进行新的建模流程？

A2：

当识别到新的 Ubiquitous Language 后，是否需要进行新的建模流程取决于具体情况和业务需求。

如果新的 Ubiquitous Language 实际对应着系统中的一个新的业务领域或限界上下文（Bounded Context），那么就需要设计一个新的领域模型，用于支持该领域或上下文中的业务规则实现。这种情况下，我们需要进行新的建模流程，确保新的领域模型能够准确地反映业务需求，并与其他领域模型协同工作。

但是，如果发现新的 Ubiquitous Language 只是现有模型中已包含的业务术语的一个不同表述，那么通常不需要开展新的建模流程。此时只需要在现有的领域模型中添加一些新的业务术语，将其与现有的术语表达方式关联起来即可。

当然，在具体情况中，可能还会出现一些其他需要考虑的因素，例如团队规模、项目进度等等。综合各种因素后，在考虑是否需要进行新的建模流程时，需要结合实际情况进行具体分析，权衡利弊。