specsfy-specialist-domain-modeling

领域建模

适用场景

• 当领域术语含义模糊、两个上下文对同一个词有不同理解，或某条规则／不变量没有明确 owner 时，使用此流程。
• 在设计新实体前，如果不清楚它属于实体、值对象、事件，还是仅仅是一个投影，也使用此流程。
• 不要用此流程决定服务拓扑、数据库或基础设施——这些属于 $specsfy-specialist-software-architecture；领域建模为这类决策提供依据，但不能替代它。
• 当新的限界上下文意味着要建立新的服务或数据边界时，将此流程与 $specsfy-specialist-software-architecture 结合使用。

流程

1. 识别参与者、他们的目标、发出的命令、已经发生的事实（事件），以及限制状态转换的规则。
2. 收集领域人员实际使用的术语——而非现有表名或类名——并揭示同义词和含义冲突。
3. 构建具体场景：正常流程、边界情况、失败情况，以及时间的影响（如果命令延迟、重复或乱序到达，会发生什么变化）。
4. 将每条不变量表述为始终成立的断言，并指定 owner（能够在写入时保证该不变量的组件／聚合）。
5. 按照必须一起变化且必须立即保持一致的行为进行分组——这决定聚合边界，而非查询便利性。
6. 用一个跨越边界的案例检验每个拟议边界：只要其中一个正确的数据就能破坏边界，说明边界划分有误。
7. 在项目的权威来源中更新词汇表、上下文映射和 ADR——切勿另建一份平行的模型文档。

模式

• 使用领域词汇（统一语言）命名，而不是技术层名称（单独使用“管理器”“处理器”“Processor”等不属于领域命名）。
• 根据各自需要体现的行为来区分实体（身份＋生命周期）、值对象（由值定义、不可变）、事件（已经发生的事实，名称使用过去时）和投影（派生的读取视图，不是真实数据来源），而非根据实现是否方便。
• 将每条不变量放在能够以原子方式保证它的组件中——依赖两个聚合且没有协调机制的不变量，在并发情况下就无法得到保证。
• 不要为了简化查询而扩大聚合；复合查询应使用投影／读取模型，而不是使用超出一致性需求的更大聚合。
• 当同一术语对应合法但互不兼容的模型时，应拆分限界上下文（例如，销售上下文中的“客户”和支持上下文中的“客户”可能有不同的属性和生命周期）。
• 事件使用过去时命名（“订单已确认”），命令使用祈使式命名（“确认订单”）——时态差异表明某件事已经发生，还是正在被请求。
• 用一个符合定义的示例和一个会推翻定义的反例来验证每项定义——没有反例的定义通常过于模糊，无法实现。

反模式

• 贫血领域模型：实体只是字段的集合（getter／setter），而所有规则都放在外部服务中——这会导致规则无法在状态变更点保证，并将规则分散到多个可能忘记执行它的调用方中。
• 在两个限界上下文中使用相同的字段／类名，并假定它们含义相同——这会迫使其中一个上下文扭曲自己的模型，以适配另一个上下文的词汇。
• 为了避免之后合并数据，让聚合覆盖“整个对象图”——这会造成写入争用，并限制领域本身并不要求限制的并发操作。
• 在权威来源（规范、代码）之外的单独文件中记录模型——只要有一次变更未同步，文档就会与实际系统不一致。

验证

• spec、代码、UI 和列名／表名中使用的语言，对同一概念保持一致，对不同上下文中的不同概念则有所区分。
• 存在用于验证每个不变量和模型中每个相关状态转换的场景（正例和反例）。
• 没有任何数据由两个所有者并发写入，且彼此不一致而未进行明确协调。
• 模型决策（术语表、不变量、边界）仅记录在项目授权的来源中，不存在可能过时的平行副本。
• 没有上述场景时，不要宣称模型“正确”——未经反例测试的模型只是一个假设，并非验证结果。

相关技能

• $specsfy-specialist-merge-conflict-resolution 在冲突涉及模型名称和不变量时保留原意。
• $specsfy-specialist-prototyping 验证领域假设，但不将原型提升为规范来源。
• $specsfy-specialist-ux-design 在用户旅程中验证术语，$specsfy-specialist-web-api-design 则将其作为公共契约公开，而不转移所有权。
• 当新的 bounded context 意味着需要服务、数据库或 deployment 边界时，使用 $specsfy-specialist-software-architecture。
• 当模型决策取决于外部系统如何定义同一概念时，使用 $specsfy-specialist-technical-research。

请阅读 references/standards.md，了解建模产物、引导性问题，以及 DDD 和 event storming 的一手资料。