Ist es eine gute Idee, Business-Logik-Code in unser Domain-Modell zu migrieren?

Question

Ich lese Hibernate in Action und der Autor schlägt vor, Business-Logik in unsere Domain-Modelle (S. 306) zu verschieben. Zum Beispiel haben wir in dem von dem Buch dargestellten Beispiel drei Entitäten mit den Namen Item, Bid und User, und der Autor schlägt vor, der Klasse Item ein placeBid(User bidder, BigDecimal amount)-Verfahren hinzuzufügen.

Angesichts der Tatsache, dass wir in der Regel eine eigene Schicht für Geschäftslogik (z. B. Manager oder Service Klassen im Frühjahr), die unter anderem steuern Transaktionen, ist dies wirklich ein guter Rat? Ist es nicht besser, unseren Entitäten keine Geschäftslogik-Methoden hinzuzufügen?

Vielen Dank im Voraus.

Answer 1

Wie gesagt

Wir haben eine ausgeprägte Schicht für Business-Logik (in der Regel genannt Service-Schicht)

Domain-Driven-Entwurf (DDD) besagt, sollten Sie die Geschäftslogik in Ihrem Domain-Modell setzen . Und glauben Sie mir, es ist wirklich gut. Wie gesagt von POJO in Buch Aktion über die Service-Schicht

• Es wird Use Case
• Es angetrieben können Transaktionsgrenzen

Vor

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

} 

Nach

definieren

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

} 

Ihre Domain Logik zeigt als

folgt

Bei der Verwendung von Domain-Driven-Entwurf, Ihre Geschäftslogik in der richtigen Stelle lebt. Aber, manchmal, könnte es eine gute Idee sein, Ihre Geschäftslogik innerhalb Ihrer Serviceebene zu definieren. Siehe here warum

Answer 2

Einer der meist zitierten Artikel zu diesem Thema ist:

"Die Anemic Domain Model" von Martin Fowler. Gut lesenswert: http://martinfowler.com/bliki/AnemicDomainModel.html

Der allgemeine Sinn ist, wenn Ihr Domain-Modell rein Daten ohne Verhalten ist, dann haben Sie viele der Vorteile von OO-Design verloren.

oder zu zitieren:

„Im Allgemeinen, desto mehr Verhalten, das Sie in den Diensten finden, desto wahrscheinlicher werden Sie sich von den Vorteilen eines Domänenmodell zu berauben Wenn alle Ihre Logik in Dienstleistungen ist. du hast dich blindlings ausgeraubt.

Answer 3

Persönlich liebe ich das anämische Modell - Daten sind Daten, Code ist Code; aber es gibt Ausnahmen.

Es kommt auf "Dichte": Wenn Sie eine große Anzahl von Diensten haben, die mit ein paar Domain-Objekten interagieren; Es ist sinnvoll, einige der gemeinsamen Business-Logik in Ihrem Domänenmodell zu setzen, damit es Teil des Dienstes wird. Wenn Sie einige Dienste haben, die mit vielen Domänenobjekten interagieren, dann bevorzugen Sie das anämische Modell gegenüber den Rich-Domain-Objekten.

Ich habe festgestellt, dass, wenn ich meine Domain-Objekte in mehreren Kontexten verwende (zB benutze ich die gleichen Domain-Objekte auf der Client-Seite und auf der Service-Seite), diese Business-Logik oft im Weg - da muss es anwendbar sein in allen Kontexten.