基于DDD的多模块订阅式单体后端架构困惑求助

核心判断 #

你的编排器设计本身是符合DDD原则的，不用过度焦虑——跨限界上下文的业务流程协调本来就是编排器的职责。但需要警惕几个常见的坑，避免编排器滥用或失控：

具体优化建议 #

• 重新校验限界上下文的划分合理性
  你把User、Role放在Core作为全局通用模块没问题，但要警惕“过度通用化”：比如是否存在某个业务模块（比如HR）需要特殊的用户角色逻辑？如果后续出现这种场景，不要硬塞到Core，而是考虑在HR上下文建立HRUserProfile这类聚合，通过上下文映射（比如共享内核或客户供应商模式）和Core的User关联，避免Core变成“大泥球”。

• 区分“业务流程编排”和“单一上下文操作”
  不是所有操作都需要编排器：如果是单个限界上下文内的业务逻辑（比如给Core的User分配Role），直接在Core内部的用例处理即可，不需要编排器介入。只有当操作涉及多个限界上下文的端到端业务流程（比如注册租户+创建管理员用户+初始化订阅），才需要编排器来协调步骤、处理异常回滚。

• 别让编排器变成“上帝对象”
  编排器只负责流程调度：它应该只是调用各个限界上下文的公开用例（比如TenantUseCase.create()、UserUseCase.createAdmin()），不包含任何具体业务逻辑。每个上下文的业务规则还是由自己的领域层和用例层维护，这样即使后续流程变化，只需要调整编排器的步骤，不用修改各个上下文的内部逻辑。

• 用领域事件替代部分编排场景
  对于非强同步的跨上下文联动，可以用领域事件解耦：比如租户创建成功后，Core上下文发布TenantCreated领域事件，User上下文监听这个事件，自动创建对应的管理员用户。这种方式比编排器硬调用更灵活，也符合DDD的事件驱动思想，能减少编排器的负担。比如原本需要编排器同时调用租户和用户用例，现在只需要租户用例发布事件，后续操作由事件触发。

• 审视“大量注册操作依赖编排器”的本质
  如果几乎所有注册操作都要跨多个上下文，先思考是不是限界上下文划分太细？比如某个模块的注册流程是否真的需要调用Core之外的多个上下文？如果是业务本身的需求，那编排器是必要的；如果是划分导致的不必要跨上下文，可以重新调整边界，把相关聚合归到同一个上下文。

• 保持数据库Schema的隔离性
  用PostgreSQL的Schema对应限界上下文的做法非常好，能从存储层面隔离各个上下文的数据，避免跨Schema的直接关联（比如不要在health.exams里直接引用core.user的主键，而是通过领域服务或上下文映射来处理关联），这个实践要坚持下去。

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