代码实现与三类架构设计的一致性检查项

把[[一致性：信息流传递中”客户价值”保持不变的特性|一致性]]落到代码实现阶段，需要分别检查与应用架构、数据架构、技术架构三方面的一致性。与应用架构的一致性包含4项：功能一致性（外部功能是否充分实现了规划的价值，内部功能是否较当初有增减——代码实现阶段常会发现之前设计有遗漏，需要分析补充）；交互一致性（各功能模块/子应用/外部系统之间的交互协议、方向、数据是否符合应用交互图的预期）；配置一致性（代码里实现的可配置参数是否真正落地、是否符合应用架构的产品化规则——代码实现阶段往往会发现更多可配置参数，需要反馈给设计者确认是否要完善）；架构风格一致性（落地的架构风格是否与应用架构阶段选定的风格相符，例如系统生命周期初期即便未来要走向分布式，也可能先用单体架构、只做内部逻辑分离为未来演变做准备，需要核实代码实现是否符合这种预期）。与数据架构的一致性包含5项：数据模型一致性（物理数据模型是否忠实反映了从业务实体模型到ER模型再到物理模型这条转化链路的思路）；数据归属一致性（每个数据模型归属的主应用不应随意变化，也要警惕数据模型被拆散到其他应用这种偏离设计初衷的情况）；数据分布一致性（数据实体在各应用的分布及主副数据源设计是否符合数据分布图）；数据流转一致性（传输方式/内容/变换过程/顺序是否满足要求）；数据集成一致性（应采集的数据是否有遗漏，聚合效应是否符合预期）。与技术架构的一致性范围较广，至少包括部署架构一致性（能否按现有部署架构要求上线）与非功能性需求一致性（技术中间件的版本基线、配置参数是否与非功功能性需求设计相符，数据类中间件的存储/时间/安全/生命周期要求是否符合设计，以及负载均衡/网关/防火墙等基础设施类产品在高并发下是否需要调整默认设置）。可迁移启发：做代码评审或上线前检查时，可以直接把这份清单当作一份”一致性体检表”逐项打勾——尤其是配置一致性和数据归属一致性这两项，是实践中最容易被悄悄破坏、却又最难在事后被察觉的一致性风险点。

结构图：

flowchart TB
  A["与应用架构的一致性"]
  A --> A1["功能/交互/配置/架构风格"]
  D["与数据架构的一致性"]
  D --> D1["数据模型/归属/分布/流转/集成"]
  T["与技术架构的一致性"]
  T --> T1["部署架构/非功能性需求(版本基线/配置参数/基础设施默认值)"]