降低一致性成本的两条思路：减少转换次数，及时反馈错误

既然[[一致性：信息流传递中”客户价值”保持不变的特性|一致性]]的保障是有成本的，可以从信息传递理论本身找思路降低成本：一是减少转换次数（每次转换都会带来一些失真），二是及时反馈错误（借鉴信息传递里的校验码技术，让接收方能验证收到的信息是否与原始信息一致）。减少转换次数具体有三种手段：统一概念（DDD里称为通用语言，业务人员、架构师、开发人员先就概念达成共识，很多架构文档里的名词解释部分正是为了消除团队内部的概念歧义）；统一模型（建模范式和编程范式要尽量一致，同时模型要有连贯性——越上游的模型越要从宏观视角考虑问题，越下游越要从微观视角思考，但上下游模型不是完全独立的，而是彼此衔接的）；统一工具和标准（各角色在不同阶段用相同的绘图工具、遵循相同的绘图风格）。及时反馈错误强调的是要有系统性的反馈方法，既包括反馈方式也包括”遇到哪些问题该反馈”：代码实现阶段发现与设计不一致是很正常的事——很难在最初就做出完美设计，资源和思路本来就是逐级解锁、逐级扩展的；而且做具体工作的人往往最了解自己的工作，即便说不清楚想法，也能感知到”哪些设计起作用、哪些不起作用”，所以应该充分发挥开发角色的反馈作用、据此持续改进已有设计；此外要特别关注代码实现阶段里那些”存在矛盾或别扭的地方”，这些地方往往隐藏着潜在的不一致（比如领域模型代码实现中不顺畅的部分；架构设计本该让开发/测试/部署/变更更便捷，一旦某个环节感觉不方便，就该重新审视架构设计本身是否妥当）。可迁移启发：团队里如果频繁出现”设计和实现对不上”的抱怨，与其一味要求”下次设计做得更完善”，不如先检查这两条基础动作有没有做到位——团队有没有统一的通用语言词汇表、开发人员反馈设计问题的渠道是不是通畅且被认真对待，这两项基础设施补齐了，比事后加强设计评审的力度更能从根源上降低一致性成本。

结构图：

flowchart TB
  C["降低一致性成本的两条思路"]
  C --> R["减少转换次数"]
  R --> R1["统一概念(通用语言/名词解释)"]
  R --> R2["统一模型(建模范式=编程范式,上下游连贯)"]
  R --> R3["统一工具和标准(绘图工具/风格一致)"]
  C --> F["及时反馈错误"]
  F --> F1["开发角色反馈设计问题(资源/思路逐级解锁,实现阶段发现不一致很正常)"]
  F --> F2["关注'矛盾别扭之处'(往往隐藏潜在不一致)"]