模块化单体架构：数据库级解耦必要性及跨模块实体共享问题

1. 若应用层需解耦，数据库层是否也需保持解耦？ #

必须保持解耦，这是应用层解耦的核心基础。如果数据库层出现耦合（比如跨schema直接查询、共享表结构），应用层的通信规则就成了摆设——模块A会直接依赖模块B的数据库设计，一旦模块B修改表结构、调整字段逻辑，模块A的业务会直接受影响，完全失去了模块化的自治性。

模块化单体的核心价值就是让每个模块能独立迭代、维护，数据库层解耦才能保证这一点：每个模块的schema完全自主管理，模块间只通过约定好的同步API或异步消息交互，后续甚至可以轻松将模块拆分为独立微服务。

2. 是否允许模块A的表外键引用模块B schema中的表？ #

绝对禁止。外键引用是数据库层面的强耦合，会引发一系列问题：

• 模块B的表若要修改主键、删除数据，模块A的表会直接触发数据库约束报错，导致操作失败；
• 跨模块的数据库事务会大幅提升复杂度，故障排查难度直线上升；
• 这直接违反了“禁止直接查询模块B的DB schema”的要求，外键依赖意味着模块A必然要关联模块B的表进行操作，彻底破坏了应用层的解耦规则。

3. 如何识别模块A与B之间的共享实体？数据库主键ID能否在模块间传递？ #

共享实体的识别 #

从业务职责和模块边界入手：

• 看业务流程中，是否存在模块A需要依赖模块B的核心数据才能完成自身业务，且该数据的所有权属于模块B（比如模块B是用户管理模块，用户信息就是它的核心共享实体）；
• 用领域驱动设计的限界上下文思路划分：每个模块对应一个限界上下文，共享实体就是上下文之间需要交互的对象，比如模块B发布的用户创建事件中的用户数据，或者模块B对外API返回的用户DTO。

主键ID的传递 #

完全可以传递，但要注意几个关键点：

• 优先使用全局唯一ID（比如UUID、雪花ID）作为传递标识，避免自增ID在跨模块时出现冲突；如果用自增ID，要给每个模块的ID加专属前缀，保证全局唯一性；
• 模块A拿到ID后，只能通过约定的通信渠道（比如调用模块B的详情API、订阅模块B的事件）获取对应数据，绝对不能用这个ID直接查询模块B的数据库；
• 模块A可以把这个ID作为普通字段存在自己的数据库里（比如命名为user_b_id），用来后续触发与模块B的交互，但绝对不能建外键关联。

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