DDD：跨子域获取实体的正确方式——从开票子域访问订单

我们逐个拆解三种方案的合理性：

方案1：开票应用服务依赖订单服务（推荐） #

这是符合领域驱动设计（DDD）子域隔离原则的正确做法：

• 每个子域对外暴露的应该是抽象的服务接口（比如OrderingService），而非内部实现细节。开票子域仅通过订单服务提供的接口获取所需数据，无需关心订单子域的内部逻辑、持久化方式。
• 这种依赖方式保持了子域的封装性，订单子域后续的内部变更（比如更换仓库实现、调整业务规则）不会直接影响开票子域，只要服务接口不变，两个子域可独立演化。
• 代码层面依赖抽象接口，符合依赖倒置原则，便于测试（可为开票服务注入订单服务的模拟实现）。

方案2：开票应用服务依赖订单仓库（不推荐） #

这种做法直接打破了子域的边界隔离：

• 仓库属于订单子域的基础设施层细节，是订单子域内部用于持久化实体的组件，对外不应暴露。开票子域直接依赖订单仓库，会耦合订单的持久化逻辑（比如数据库表结构、ORM框架），一旦订单子域更换仓库实现（比如从SQL切换到文档数据库），开票子域必须同步修改，维护成本极高。
• 这种方式相当于让开票子域直接操作其他子域的数据源，违反了子域的业务边界，容易引发跨子域的数据一致性问题。

方案3：在开票子域定义自定义Order实体/值对象（可行，但需按需设计） #

这种方案是可行的，但要明确开票子域需要的订单数据范围：

• 如果开票只需要订单的部分核心信息（比如订单ID、应付金额、客户ID、收货地址），完全可以在开票子域定义一个Order值对象（或简化版实体），仅包含自身业务需要的字段。此时无需合并子域，因为两个子域的业务上下文完全不同：订单子域负责订单的生命周期管理（创建、修改、取消等），开票子域负责发票的生成、校验、归档，各自的业务规则独立。
• 实现时，开票子域仍需通过订单服务获取完整订单数据，再转换为自身的Order值对象，避免直接依赖订单子域的实体。
• 只有当两个子域的业务逻辑高度耦合、几乎无法独立演化时，才需要考虑合并子域，但这种情况在订单和开票的场景中很少见，因为两者的业务目标差异明显。

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