业务实体管理系统多语言支持重构

架构实践：翻译表分离 + 服务层装配

在多语言业务场景中，为现有业务实体（Product、Vehicle、RealEstate 等）增加国际化支持，核心矛盾在于：既要保留原有数据模型的稳定性，又要实现按语言动态返回字段值。

本方案采用“主表存事实数据 + 翻译层存语义 + 服务层统一装配”的架构，实现了零侵入式的多语言扩展。

1. 架构设计思想：职责分离与解耦

核心理念在于将“业务逻辑”与“语言逻辑”完全剥离：

• 数据解耦：主业务表仅存储业务事实（默认值/标识），翻译内容完全剥离至独立表。
• 逻辑解耦：原有查询服务不感知多语言，翻译装配仅在 DTO 转换的最后阶段完成。
• 扩展性优先：通过字段注册表白名单机制，新增可翻译字段或语言仅需调整数据，无需修改表结构。

设计原则：符合开闭原则（OCP），避免了“全表增加多语言列”或“强制大表 JOIN”的性能陷阱。

2. 数据库层实现：声明式分区与注册机制

通过 PostgreSQL 的声明式分区（Declarative Partitioning）实现逻辑统一与物理隔离。

核心表结构

• 字段注册表 i18n_field_registry：记录 (entity_type, field_key) 白名单。
• 翻译父表 i18n_translation_base：
  • 分区子表：按实体类型划分为 i18n_product_t、i18n_vehicle_t 等。
  • 关键字段：entity_id、field_key、language_code、translated_value。
• 约束与索引：
  • 唯一约束：(entity_id, field_key, language_code, region_code)。
  • 复合索引：针对 (entity_type, entity_id) 优化批量查询。

3. 服务层组件架构

新增独立的 i18n 模块，包含以下核心无状态组件：

4. 读链路核心：无侵入式翻译装配

这是本方案最精妙的“无感封装”环节。系统不再通过 SQL JOIN 强行关联翻译，而是在 DTO 组装完成后，通过 AOP 或 Service 装饰器进行动态覆盖：

核心步骤：

1. 批量拉取候选：系统识别 DTO 集合，通过 entity_type + entity_id + field_key 组合，单次 SQL 批量拉取所有相关的翻译备选记录。
2. Locale 回退链匹配：根据用户当前的语言环境（如 zh-HK），按预设回退链（zh-HK → zh-CN → en）在内存中过滤出最优翻译值。
3. TranslationApplierService 自动覆盖：由专用的装配服务通过反射或映射工具，将命中的翻译值精准“覆盖”到 DTO 的对应字段上。

效果：原有的 ProductService 代码逻辑一行不改，返回给前端的 JSON 却已根据用户语言完成了动态替换。

5. 方案优势分析

• ✅ 非侵入性：原有业务主表结构、历史数据、既有 SQL 完全无需改动。
• ✅ 高扩展性：支持“即插即用”，新增实体类型只需添加分区和配置。
• ✅ 一致性强：唯一约束从底层杜绝重复，分区剪枝保证了大数据量下的查询性能。
• ✅ 低耦合度：翻译逻辑高度内聚，对业务代码的干扰降至最低。

6. 潜在不足与改进方向

在享受灵活性的同时，需注意以下权衡：

• 查询开销：详情查询增加了一次翻译表的 Round-trip。
  • 优化方案：引入 Redis 二级缓存 存储热点翻译。
• 事务一致性：主表与翻译表存在双写问题。
  • 优化方案：采用 Transactional 或 Outbox Pattern 确保原子性。
• 外键限制：PostgreSQL 分区表不支持跨分区外键。
  • 优化方案：在应用层强化校验逻辑。

7. 业界应用与架构总结

核心架构思想：从“属性”到“视口 (Viewport)”

本方案最本质的突破在于思维模型的转变：不再将多语言视为数据本身的“固有属性”，而是将其视为一种“观察视角”。

• 传统模式：将翻译强行塞入主表，导致数据库结构随语言种类膨胀，属于纵向耦合。
• 本方案（Viewport 模式）：主表记录物理世界的“客观事实”，翻译层根据用户的 Locale 提供特定的“语义视窗”。这种横向切分确保了核心业务模型的简洁与纯粹。

实现逻辑本质：三位一体的无侵入装饰

通过以下链路的闭环，实现了业务代码逻辑的“零污染”：

1. 批量拉取（Batching）：系统在 DTO 组装完成后，基于 entity_type + entity_id + field_key 仅发起一次高效的批量查询。
2. 内存回退（Memory Fallback）：利用 LocaleFallbackChain 在内存中快速执行回退算法（如 zh-TW → zh-CN → en），避免了多次数据库交互。
3. 动态覆盖（Decoration）：由 TranslationApplierService 像“贴纸”一样将翻译值精准覆盖到 DTO 字段。

最终总结

通过**“分区表 + 注册表 + 服务层装饰装配”的组合拳，本方案实现了多语言能力的即插即用**：

架构本质： 它是对核心业务逻辑的横向解耦。 既保证了数据库底层的高性能与强一致性，又赋予了上层应用极高的灵活性。它不仅解决了多语言存储的难题，更提供了一套通用的、可扩展的业务实体增强框架，为系统的全球化运营奠定了坚实的架构底座。