用途：这条技能用于在编写有状态逻辑时，以及当代码分支很多、或在多个文件里重复同一种形状假设时，把真实的领域编码进数据结构，而不是把领域知识散落在条件判断中。结构与领域匹配时，非法状态会变得不可表示，分支会被删除。在编写时选好结构成本很低；事后恢复结构会被视为重构而被推迟。
可优先考虑的结构：用状态机代替零散的布尔值、阶段或生命周期检查；用带类型的模型代替松散参数或重复的形状假设；用映射、注册表、查找表或可辨识联合代替散布在多个文件中的分支；用 reducer 或命令/事件模型代替临时性的状态修改；用围绕一份领域知识组织的模块代替“加载、校验、转换、保存”这类按执行顺序划分的模块，执行顺序不等于所有权；用小的模块边界收拢重复行为、所有权或不变式；在访问模式需要时使用队列、缓存、索引、图、树或规范化集合；也可使用其他任何合适的结构。若没有合适结构，先弄清代码绝不允许发生什么、数据如何被读取，再找出恰好能编码这些约束的结构。
命名：使用领域自身的词汇。命名类型、函数和模块前，先阅读就近的术语表（如项目文档中的 CONTEXT.md 或 glossary），并使用其中的术语；绝不使用术语表标记为应避免的词。按操作在领域中的效果命名，而不是按执行机制命名。
限制与反模式：不要强行抽象。如果当前形状已经清晰、局部且不太可能增长，优先选择无聊的代码。对只增加间接层却没有消除分支、重复规则、非法状态或生命周期风险的抽象保持怀疑。跳过本原则的信号是：新功能让已有的 if/else 链又多一个分支，或出现第二个必须与第一个保持同步的布尔值；按时间分解也是信号，以阶段命名的模块会在各步骤中重复同样的领域规则。
评审时还应检查三点：概念命名唯一，若代码已为某概念命名，标记新造的名字，修正方向是沿用代码中的词；区分上下文，同一个词在不同部分可能指不同概念，不要把二者合并成一个字段按含义可选的类型，修正方向是各部分使用独立类型，仅共享含义相同的部分如 id，收敛针对的是一个概念而不是一个词；共享代码要对每个调用方负责，列出改动涉及的共享函数、类型或常量的调用方，标记为单个需求而改变其他业务功能调用方行为的情况，修正方向是分叉该共享部分、只改请求方的路径，不同业务功能会各自修改的相似代码是两个决策，不应要求合并。