DDD战略设计中全局字典归属问题：归特定领域还是共享模块？

核心原则：别死磕“全局”，看业务关联 #

DDD里没有绝对的“全局公共模块”，但这类通用字典确实有特殊处理方式，分两种典型场景：

1. 纯静态映射的字典（无业务规则） #

如果国家/货币只是纯代码+名称的静态对应，没有任何业务逻辑（比如不需要验证某货币是否支持结算、某国家是否在准入名单），那直接做成**独立的基础库（Shared Kernel）**就行——这是DDD官方认可的共享组件，专门放跨领域通用的、无业务逻辑的基础元素。

• 好处：避免各领域重复定义，保证数据一致性；基础库只负责维护标准数据（比如ISO官方的国家/货币代码），不掺和任何业务逻辑。
• 注意：这个库只能存纯数据结构或简单查询方法（比如getCountryNameByCode(code)），绝对不能加业务规则。

2. 带业务规则的字典 #

如果某个领域对这些字典有专属业务逻辑（比如电商领域要限制仅支持特定国家下单、金融领域要验证货币的结算规则），那必须在对应领域内定义领域专属的枚举/值对象：

• 比如电商领域的AllowedCountry值对象，封装“允许下单的国家列表”这个业务规则；金融领域的SettableCurrency，包含“可结算货币的校验逻辑”。
• 这时候基础库的纯字典可以作为底层数据源，但领域内的对象要自己封装业务规则，不能直接暴露基础库的内容。

关键误区：别把“数据一致”当成“必须全局共享” #

很多人误以为“各领域用的国家代码一样”就要做全局模块，但DDD的核心是领域边界内的业务自治：

• 如果只是数据格式一致，用Shared Kernel完全没问题；但如果涉及业务规则，哪怕数据看起来一模一样，也要归到对应领域，避免跨领域耦合。
• 举个例子：同样是国家代码，物流领域关注“是否支持配送”，用户管理领域只需要“用于身份验证的合规代码”，这俩是不同的业务概念，只是刚好复用了相同的代码值而已。

实践落地建议 #

• 拆分处理：把纯数据部分抽成Shared Kernel，业务规则部分留在对应领域各自实现。
• 别过度设计：如果当前所有领域都只用到纯数据，先做基础库就行，等出现专属业务规则再在领域内扩展。
• 管控维护：Shared Kernel最好由架构团队统一维护，避免各领域随意修改，保证数据的标准性和一致性。

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