Web应用中base36 ID编解码的架构层归属及一致性问题咨询

核心问题解答 #

1. 最适合的职责层：应用层 #

应用层是处理Base36编解码的最优选择，原因如下：

• 领域层纯净性：领域层只负责核心业务规则与实体逻辑，Base36是对外交互的格式适配逻辑，不属于业务范畴，放入领域层会污染核心模型，增加后续变更（如换用Base62）的成本。
• 避免重复实现：应用层作为对外接口（Web、API、CLI）与内部层（领域、基础设施）的中间层，可统一处理编解码逻辑，避免多接口重复开发，保证一致性。
• 内部效率保留：领域层与数据库仍使用整数ID，维持存储与业务逻辑的高效性，仅在对外输出/接收时转换为Base36。

2. 所有接口应统一使用Base36 ID #

必须统一。你的场景明确要新增REST API、CLI等多接口，统一标识符带来的好处包括：

• 开发效率提升：无需为不同接口维护不同ID格式的转换逻辑，减少重复代码。
• 用户体验一致：同一资源在Web、API、CLI中使用相同的短ID，降低用户认知成本。
• 维护成本降低：后续变更ID格式时，仅需修改应用层的统一转换逻辑，无需逐个调整接口。

3. 统一使用Base36不代表要归属领域层 #

完全不是。Base36是对外展示的格式适配，而非核心业务规则。领域层的职责是封装业务实体与规则，若将Base36 ID放入领域模型，会导致：

• 实体逻辑混入非业务的格式转换代码，违反单一职责原则。
• 后续更换编码方式（如Base62）时，需修改所有领域实体，风险极高。
• 数据库存储与领域模型的ID类型不一致，增加数据映射的复杂度。

各分层方案点评 #

1. 表现层（HTTP处理器转换） #

不推荐：仅适合单Web接口场景，多接口（API、CLI）会重复实现编解码逻辑，极易出现不一致，维护成本高。

2. 应用层（服务中转换） #

推荐：完美匹配你的需求：

• 数据库与领域层使用整数ID，保证内部效率。
• 应用层统一处理编解码，对外所有接口输出Base36 ID，保证一致性。
• 新增接口时直接复用应用层的转换逻辑，扩展性强。

3. 领域层（领域模型中转换） #

不推荐：污染领域模型，将格式适配逻辑混入核心业务代码，后续变更成本极高，违反DDD的分层原则。

4. 基础设施层（数据访问中转换） #

不推荐：基础设施层的职责是数据持久化，将编解码逻辑放入此处会导致领域层依赖外部格式，同样污染核心模型，且不符合分层职责划分。

内容的提问来源于stack exchange，提问作者BARJ