DDD: posizionamento di un metodo il cui comportamento può essere implementato con una singola query di database

Question

DDD: posizionamento di un metodo il cui comportamento può essere implementato con una singola query di database

#1 da (1 voti)

3

Supponiamo di avere un'entità Book nella nostra libreria. Un requisito dice:

Librarian may disable 'available' flag to books published before some year. For example, librarian may 'hide' some old books from being publicly available as they are rare.

Questo comportamento è facilmente eseguibile con un singolo comando SQL. Il nome del metodo per questo comportamento potrebbe essere ad es. hideBooksPriorToYear() .

Ma dove mettere questo metodo?

se lo inseriamo nel repository, presto sarà pieno di tali metodi; inoltre, questo è un metodo di business, non un metodo di repo.
potremmo recuperare tutti i vecchi libri e nasconderne uno per uno, ma questo è lento.
potremmo creare un servizio aziendale per questo, ma sembra di nuovo un modello anemico
potremmo mettere questo metodo in un modello, ma non voglio mettere sql lì.

Qualche saggezza su questo?

Modifica

Cercando di chiarire. Quando provo a spostare il comportamento sui metodi delle entità, ho scoperto che la maggior parte del business non è disponibile senza un repo. E non voglio iniettare istanza di repo nei modelli. In questo modo le mie entità inizieranno presto a essere: 1) oggetti dati semplici e 2) fabbriche per entità / aggregati correlati al modello.

domain-driven-design architecture

posta lawpert 30.10.2014 - 15:23

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design architecture

In WPF, dovrei basare i miei convertitori su tipi o casi d'uso? Devo gettare eccezioni di protezione che saranno comunque lanciate dai metodi interni? [duplicare]

score 1 · Accepted Answer

Nel tuo caso particolare, come regola generale, i metodi che operano su una singola entità dovrebbero essere definiti sul modello stesso, mentre quei metodi che operano sulla collezione di entità nel suo insieme dovrebbero essere definiti sul servizio.

Metodi come getLatest , getMostPopular , getOutOfStock , deleteFromPublisher , deleteFromAuthor sono tutti candidati ideali per essere definiti sul servizio nella tua architettura, poiché tali query controllerebbero tutte le entità esistenti.

Per contrasto, metodi come delete , hide , setStock , setPrice dovrebbero idealmente essere definiti sul modello stesso, poiché li utilizzeresti su una particolare entità che hai nel contesto corrente.

La tua preoccupazione che tu possa finire con molti di questi metodi sul servizio è soggettiva. Dal punto di vista della manutenzione, ci sono modi per affrontarlo se diventa insopportabile, ma non cambia il fatto che questi dovrebbero essere qualificati dall'oggetto di servizio stesso.