业务逻辑应该放在领域层还是服务层？

Question

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

```java public void addItemToCart(Item item) { if (!cart.contains(item)) { cart.add(item); } } ```

请注意，`contains()` 方法用于检查集合中是否已经存在该商品。如果不存在，则将其添加到购物车中。

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

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

另一种选择是创建一个处理此事务的服务（例如ShoppingCartService），它将执行业务逻辑并发送电子邮件。然而，这会导致一个相当贫血的领域（即User类仅仅是getter/setter）。

- Kevin Pang

---

如果网站管理员正在进行电话订单，会发生什么情况？您确定在这种情况下User.AddItemToCart是一个合适的设计吗？ - Todd Smith

Answer 1

作为用户领域逻辑的一部分，应该将其保留在用户中。这可能涉及使用服务来注入用户实体。我认为这取决于服务是否是用户类的业务逻辑的一部分，以及这样做是否符合您的通用语言。

我的写法如下：

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");
    }
}

这个相关问题有一些讨论可能对你有帮助。

我建议你尽可能将getter和setter的作用域限制得更小，以减少耦合。

- moffdub

Answer 2

然而，这会导致一个相当贫乏的领域（即User类只是getter/setter）。

User并不是整个领域。

你还有Cart、Item和复杂的Cart.add()，将Item放入Cart中。

那么，如果User类看起来很简单又怎样呢？

- S.Lott

Answer 3

保持方法不变，然后创建一个服务类来处理事务。当调用服务类方法时，您可以在那里注入您的电子邮件逻辑。

- Jobo

Answer 4

在大型系统中，User类最终会有很多不同类型的操作。该类可能会变得太庞大。为了避免这种情况，应该有其他类来为用户执行任务。

- Silvercode