DDD聚合方法入参为其他聚合时校验是否适合用领域服务？

设想存在Product和Order两个领域聚合，Order实例可通过OrderLine类关联多个Product作为订单行项，相关核心类定义如下：

public class Order {
    // ...其他属性、方法
    Set<OrderLine> orderLines; 
    public void addProductToOrder(Product product) {
        // 待实现逻辑
    }
    // ...其他属性、方法
}

public class Product {
    // ...其他属性、方法
    int stock;
    boolean isProductOutOfStock(int quantity) {
        return stock - quantity < 0;
    }
    // ...其他属性、方法
}

现需要实现「将商品添加到订单」的业务场景，最初设计的应用服务方法逻辑仅包含单步操作：

{
    order.addProductToOrder(Product product);
}

当前设计存在两个明确的约束：

• 根据聚合的设计原则，单个聚合仅需维护自身的不变量，因此不建议在order.addProductToOrder方法内部直接调用product.isProductOutOfStock执行库存校验。
• 应用服务的定位是流程编排，不应承载业务决策逻辑，因此库存校验逻辑也不能放置在应用服务层实现。

当前场景下是否适合创建领域服务来承载该跨聚合的库存校验逻辑？

完全适合，这就是领域服务的标准适用场景。
领域服务的核心作用就是承接那些不适合归属于单个聚合/实体/值对象的业务逻辑——当一个业务规则需要协调多个独立聚合的状态才能完成判断、决策，且逻辑本身属于核心业务规则而非流程编排逻辑时，就应该将其放到领域服务中实现，从架构层面保证所有核心业务逻辑都收敛在领域层，不会泄露到应用服务。

这个场景的标准实现路径如下：

• 应用服务只做无业务判断的流程编排：根据请求参数加载对应的Order聚合、待添加的Product聚合，将两个聚合实例传入对应领域服务的方法，待领域逻辑执行完成后，调用资源库持久化变更后的聚合即可。
• 新建订单相关的领域服务（例如命名为OrderPurchasingDomainService）承载核心业务逻辑：首先调用传入的Product实例的isProductOutOfStock方法，传入本次购买的商品数量做库存校验，如果库存不足直接抛出对应的业务异常；校验通过后，再调用Order实例的addProductToOrder方法完成订单行项的添加。

需要额外注意：不要为了少写一层代码，直接在Order聚合内部注入Product的资源库查询库存做校验，这种写法会破坏聚合的自治性，把跨聚合的依赖隐藏在聚合内部，后续迭代很容易引发并发问题、逻辑泄露问题。

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