¿Debe colocarse la lógica comercial en el dominio o los servicios?

Question

Digamos que tiene un usuario de entidad de dominio y desea apoyar la capacidad de un usuario para agregar un artículo a su carrito de compras. Ahora, queremos asegurarnos de que los elementos de la cesta de la compra son únicos, por lo que creamos la siguiente función dentro de la clase Usuario:

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

Esto funciona muy bien. Pero, ¿y si ahora también queremos enviar un correo electrónico al usuario cada vez que se agrega un artículo a su carrito? Podemos agregar esto en AddItemToCart, pero requeriría inyectar algún tipo de dependencia IEmailer en la clase User.

La alternativa sería crear un servicio para manejar esta transacción (por ejemplo, ShoppingCartService) que llevaría a cabo la lógica comercial y enviaría el correo electrónico. Sin embargo, esto conduce a un dominio bastante anémico (es decir, la clase de usuario no es más que getters/setters)

Answer 1

La lógica que es parte de la lógica de dominio del usuario debe permanecer en el usuario. Esto puede o no implicar la inyección de un servicio a la entidad Usuario. Creo que depende de si el servicio es parte de la lógica comercial de la clase de usuario, y si esto se ajusta a su lenguaje ubicuo.

que iba a escribir esto:

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 tiene discusión que pueden ser útiles.

También le aconsejo que mantenga los getters y setters tan restringidos como sea posible para reducir el acoplamiento.

Answer 2

Mantenga el método como está, luego cree una clase de servicio para manejar la transacción. Cuando se realiza la llamada al método de clase de servicio, puede insertar allí su lógica de correo electrónico.

Answer 3

"Sin embargo, esto conduce a un dominio más bien anémica (es decir, la clase de usuario no es más que getters/setters)"

el usuario no está todo el dominio.

Tiene un Carro, Artículo, y un sofisticado Cart.add() que pone Artículos en el Carro.

¿Qué ocurre si la clase de usuario parece simplista?

Answer 4

En sistemas grandes, la clase de usuario terminaría teniendo muchos tipos diferentes de operaciones. La clase puede ser demasiado grande. Para evitar eso, debería haber otras clases que hagan cosas para el usuario.