¿Es una buena idea "migrar el código de lógica de negocios a nuestro modelo de dominio"?

Question

Estoy leyendo Hibernate en acción y el autor sugiere mover la lógica comercial a nuestros modelos de dominio (página 306). Por ejemplo, en el ejemplo presentado por el libro, tenemos tres entidades llamadas Item, Bid y User y el autor sugiere agregar un método placeBid(User bidder, BigDecimal amount) a la clase Item.

Teniendo en cuenta que generalmente tenemos una capa distinta para la lógica de negocios (por ejemplo, Manager o Service clases en Spring) que entre otras cosas controla transacciones, etc. ¿es realmente un buen consejo? ¿No es mejor no agregar métodos de lógica de negocios a nuestras entidades?

Gracias de antemano.

Answer 1

Como se ha dicho

Tenemos una capa distinta de la lógica de negocio (generalmente llamada capa de Servicio)

Domain-Driven-Design (DDD) afirma que usted debe poner la lógica de negocio dentro de su modelo de dominio . Y, créanme, es realmente bueno. Según lo dicho por POJO en Acción libro sobre la capa de servicio

• Se Caso de Uso impulsado
• Puede definir los límites de transacción

Antes

@Service 
public class BidServiceImpl implements BidService { 

    @Autowired 
    private ItemRepository itemRepository; 

    public void placeBid(Integer itemId, User bidder, BigDecimal amount) { 

     Item item = itemRepository.getById(itemId); 

     if(amount.compareTo(new BigDecimal("0.00")) <= 0) 
      throw new IllegalStateException("Amount must be greater than zero"); 

     if(!bidder.isEnabled()) 
      throw new IllegalStateException("Disabled bidder"); 

     item.getBidList().add(new Bid(bidder, amount)); 
    } 

} 

Después

@Service 
public class BidServiceImpl implements BidService { 

    @Autowired 
    private ItemRepository itemRepository; 

    public void placeBid(Integer itemId, User bidder, BigDecimal amount) { 
     // itemRepository will retrieve a managed Item instance 
     Item item = itemRepository.getById(itemId); 

     item.placeBid(bidder, amount); 
    } 

} 

Su lógica de dominio es el programa de la siguiente manera

Al utilizar Driven-Domain-diseño, la lógica empresarial vive en el lugar correcto. Pero, veces, podría ser una buena idea definir su lógica de negocio dentro de su capa de Servicio. Ver here qué

Answer 2

Uno de los artículos más citados en esto es:

"El modelo de dominio anémico", de Martin Fowler. Bien vale la pena leer: http://martinfowler.com/bliki/AnemicDomainModel.html

La esencia general es que si su modelo de dominio es puramente datos sin ningún comportamiento, habrá perdido muchos de los beneficios del diseño OO.

o para citar:

"En general, cuanto más el comportamiento que se encuentra en los servicios, más probabilidades hay de estar robando a ti mismo de los beneficios de un modelo de dominio Si toda tu lógica es en los servicios,. te has robado a ti mismo a ciegas ".

Answer 3

Personalmente me encanta el modelo anémico - los datos son datos, el código es el código; pero hay excepciones

Todo se reduce a 'densidad': si tiene una gran cantidad de servicios que interactúan con algunos objetos de dominio; Tiene sentido poner parte de la lógica de negocio en su modelo de dominio, por lo que se convierte en parte del servicio. Si tiene algunos servicios que interactúan con muchos objetos de dominio, entonces favorezca el modelo anémico sobre los objetos de dominio enriquecido.

He encontrado que si uso mis objetos de dominio en contextos múltiples (por ejemplo, uso los mismos objetos de dominio en el lado del cliente y en el servicio) la lógica de negocios a menudo se interpone en el camino, ya que debe ser aplicable en todos los contextos.