domain-driven-design - 业务逻辑应该放在领域还是服务中？

Question

假设您有一个域实体用户，并且您希望支持用户将商品添加到他们的购物车的能力。现在，我们要确保购物车中的商品是唯一的，因此我们在 User 类中创建以下函数:

function AddItemToCart(Item item)
{
    // Add business logic to make sure item is unique
}

这很好用。但是，如果我们现在还想在将商品添加到购物车时向用户发送电子邮件怎么办？我们可以将它添加到 AddItemToCart 中，但它需要将某种 IEmailer 依赖项注入(inject)到 User 类中。

另一种方法是创建一个服务来处理此事务(例如 ShoppingCartService)，该服务将执行业务逻辑并发送电子邮件。然而，这导致了一个相当贫乏的领域(即 User 类不过是 getter/setter)

Answer 1

作为用户域逻辑的一部分的逻辑应该留在用户中。这可能涉及也可能不涉及向用户实体注入(inject)服务。我认为这取决于服务是否是 User 类的业务逻辑的一部分，以及这样做是否符合您的普遍语言。

我会这样写:

class ShoppingCartService
{
    private EmailService emailer;

    public void addItemToUserCart(User u, Item i)
    {
        u.addItemToCart(i);
        this.emailer.sendEmailTo(u, "Item " + i.toString() + " was added to your cart");
    }
}

This related question进行讨论，您可能会觉得有帮助。

我还建议您尽可能限制 getter 和 setter 的范围以减少耦合。