DDD: mettere la logica in servizio o la radice aggregata?

2

Diciamo che stiamo costruendo un sistema di gestione dei documenti.

Un progetto ha molti documenti. Decido di creare progetti come radice aggregata.

Se la logica per aggiungere un documento al progetto è complicata, posso inserirlo in una radice aggregata come:

class Project
{
    public function addDocument($params){}
}

Ma posso anche fare di questo solo un servizio di dominio

class ProjectService
{

    public function addDocument($project, $params){}

}

Qual è la differenza?

Come decidere quale usare?

Grazie!

    
posta 尤川豪 20.06.2015 - 09:59
fonte

1 risposta

3

Project.addDocument è l'approccio giusto.

Il principio guida è la definizione di un aggregato.

AGGREGATE A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. A set of consistency rules applies within the aggregate's boundaries.

In altre parole, se si dispone di una raccolta di documenti, tutte le regole di coerenza per la raccolta di documenti appartengono alla raccolta, tutte contenute in una radice aggregata.

L'inserimento delle regole di coerenza in un servizio di dominio tende a generare un modello di dominio anemico , un anti-pattern .

Nelle , tutto il lavoro di modifica dello stato appartiene all'aggregato ; I servizi di dominio stateless forniscono il supporto di query all'aggregato che sta valutando una modifica.

Avviso: esempio forzato avanti

Ad esempio, se stavi cercando di implementare l'invariante che un progetto non può includere più di $ 20 di documenti, potresti vedere una firma come

class Project
{
    public function addDocument($document, $documentPricingService){}
}

Il servizio di tariffazione saprebbe come calcolare il prezzo di un documento o anche una raccolta di documenti, ma non saprebbe nulla della regola secondo cui il totale deve essere inferiore a $ 20. Il progetto saprebbe come passare la raccolta di documenti (aggiornata) al servizio di dominio per i prezzi, ma non per quanto riguarda il modo in cui il prezzo è fatto.

In genere, il componente dell'applicazione è responsabile della ricerca del servizio di determinazione del prezzo prima di eseguire il comando Project.addDocument.

    
risposta data 29.01.2016 - 05:20
fonte

Leggi altre domande sui tag