业务逻辑应该放在域还是服务中?

Kev*_*ang 5 domain-driven-design

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

function AddItemToCart(Item item)
{
    // Add business logic to make sure item is unique
}
Run Code Online (Sandbox Code Playgroud)

这非常有效.但是,如果我们现在想要在项目添加到购物车时也通过电子邮件发送给用户呢?我们可以将它添加到AddItemToCart中,但它需要将一些IEmailer依赖项注入User类.

另一种方法是创建一个服务来处理这个事务(例如ShoppingCartService),它将执行业务逻辑并发送电子邮件.然而,这会导致一个相当贫乏的领域(即用户类只不过是getter/setters)

mof*_*dub 4

作为用户域逻辑一部分的逻辑应该保留在用户中。这可能涉及也可能不涉及向用户实体注入服务。我认为这取决于该服务是否是 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");
    }
}
Run Code Online (Sandbox Code Playgroud)

这个相关问题的讨论可能会对您有所帮助。

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