principle-model-the-domain

对领域建模

将真实领域编码到数据结构中，而不是把它分散在各个条件判断里。与领域相匹配的结构能让无效状态无法表示，并减少分支。在编写代码时选择这种结构，成本很低；事后再补救，看起来就像一次重构，因此往往会被推迟。

优先考虑：

• 用状态机代替散落的布尔值、阶段或生命周期检查。
• 用类型化模型代替松散的参数或反复假设数据形状。
• 用映射、注册表、查找表或判别联合代替散布在多个文件中的分支。
• 用 reducer 或命令／事件模型代替临时的状态修改。
• 用围绕一组领域知识组织的模块，代替按加载、验证、转换、保存等步骤组织的模块。执行顺序不等于归属。
• 用小型模块边界汇集重复行为、归属关系或不变量。
• 根据访问模式，选择队列、缓存、索引、图、树或规范化集合。
• 也可以使用其他合适的结构。如果都不适用，就先弄清代码绝不能允许什么，以及数据会如何被读取，然后找到能精准表达这些要求的结构。

使用领域中的词汇。 类型、函数和模块的命名应使用领域中的词汇。在命名之前，先查阅最近的术语表（如果有），例如 CONTEXT.md 或项目文档中的术语表，并使用其中的术语。切勿使用术语表标明应避免的词。操作的命名应体现它在领域中的效果，而不是执行该操作的机制。

不要强行引入抽象。如果现有结构已经清晰、局部且不太可能扩展，就优先采用朴素代码。对那些只增加间接层，却没有减少分支、重复规则、无效状态或生命周期风险的抽象，保持审慎。

如果你跳过了这一步，通常会出现这样的迹象：新功能让现有的 if/else 链又多出一个分支，或者又增加了一个必须与第一个保持同步的布尔值。按时间阶段拆分也是一种迹象。以阶段命名的模块会在多个步骤中重复相同的领域规则。

代码评审时。 评审他人的改动时，还要检查以下三点。

• 一个概念只用一个名称。 如果代码已经为某个概念命名，就指出新增的别名。修正方向是沿用代码中的词汇。
• 上下文分开。 同一个词在代码库的不同部分可能指代不同概念。如果某项改动将它们合并为一个类型，并根据含义将字段设为可选，就应指出。修正方向是在各部分分别定义类型，只共享两边含义相同的内容，例如 id。只有同一个概念才应收敛，而不是仅仅因为词相同。
• 共享代码要回应每位调用者的需求。 列出改动涉及的每个共享函数、类型或常量的调用者。如果某项改动是为一个请求而做，却改变了服务另一种业务功能的调用者的行为，就应指出。修正方向是复制共享部分，只修改请求方使用的路径。不同业务功能各自修改的相似代码，代表不同的决策，因此不要要求将它们合并。