Il livello del servizio applicativo può creare un'istanza di una radice non aggregata?

Question

Il livello del servizio applicativo può creare un'istanza di una radice non aggregata?

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

1

Dire che ho una radice aggregata chiamata Cliente. In questo esempio, il cliente ha una raccolta di fatture.

È mai "accettabile" che il livello del servizio applicativo crei un'istanza della classe Invoice? La classe di fatturazione non è la radice aggregata.

Mi rendo conto che non è "accettabile" per nessuna radice aggregata da un altro aggregato per accedere alla classe Customer, tuttavia ho vagato se questo si applica anche al Servizio Applicazione.

Sto parlando dal punto di vista di un purista del DDD. Mi rendo conto che DDD non è sempre la scelta migliore per risolvere un problema - sto solo cercando di migliorare il mio modo di pensare in questa specifica area.

Aggiorna

Vedi il codice qui sotto:

public class InvoiceService
{

 Invoice Invoice;

 public InvoiceService(Invoice invoice)
 {
   Invoice=invoice;
 }

 public void DoSomething()
 {
   Invoice.DoSomething();
 }

}

Sto chiedendo se è "accettabile" accedere all'oggetto dominio Invoice da un servizio applicativo anche se non è una radice aggregata, cioè tutte le azioni della fattura devono passare attraverso Customer.Invoices invece di Fatture.

c# domain-driven-design design-patterns

posta w0051977 07.11.2017 - 16:43

fonte

3 risposte

2

Se per DDD Purist intendi qualcuno che segue il libro di Eric Evans alla lettera allora non va bene. Evans chiarisce che le classi che non sono radici aggregate non possono essere recuperate da nessun posto se non attraverso una radice aggregata. Da pagina 92:

Now, to translate that conceptual AGGREGATE into the implementation, we need a set of rules to apply to all transactions:

The root ENTITY has global identity, and is ultimately responsible for checking invariants.

Root ENTITIES have global identity. ENTITIES inside the boundary have local identity, unique only within the AGGREGATE.

Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY. The root ENTITY can hand references to the internal ENTITIES to other objects, but those objects can only use them transiently, and may not hold onto the reference. The root may hand a copy of a value to another object, and it doesn’t matter what happens to it, since it’s just a value and no longer will have any association with the AGGREGATE.

As a corollary to the above rule, only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations.

Objects within the AGGREGATE can hold references to other AGGREGATE roots.

A delete operation must remove everything within the AGGREGATE boundary at once. (With garbage collection, this is easy. Since there are no outside references to anything but the root, delete the root and everything else will be collected.)

When a change to any object within the AGGREGATE boundary is committed, all invariants of the whole AGGREGATE must be satisfied.

Stranamente, uno dei suoi prossimi esempi è di una classe simile a una fattura, e sottolinea che la Fattura è una radice aggregata nel suo esempio. Se ti stai riscontrando questo problema, forse è un segno che anche una Fattura è una radice aggregata nel tuo sistema.

Non solo, ma la tua domanda in particolare sembra essere specifica sul fatto che il livello del servizio applicativo possa creare o meno un oggetto dominio . Penso che la risposta sia abbastanza chiara. No. Evans ha una sezione del libro dedicata al ciclo di vita degli oggetti di dominio ed è abbastanza chiaro che le Fabbriche hanno questa responsabilità. Inoltre, vorrei indirizzare la tua attenzione a pagina 76 e alla sezione intitolata SERVIZI e il livello di dominio isolato in cui fornisce la seguente tabella:

Partitioning Services into Layers

Application

Funds Transfer App Service:

Digests input (e.g. XML request)

Sends message to domain service for fulfillment

listens for confirmation

decides to send notification using infrastructure service.

Domain

Funds Transfer Domain Service:

Interacts with necessary Account and Ledger objects, making appropriate debits and credits, supplies confirmation of result (transfer allowed or not, etc.)

Infrastructure

Send Notification Service:

Sends emails, letters, etc. as directed by application.

Sulla base di questa comprensione dei Servizi, penso che un purista del DDD si possa ritorcere contro l'idea di un oggetto Fattura creato all'interno di un Servizio Applicazione. Naturalmente, tutto questo presuppone che l'uso del termine "Application Service" corrisponda all'utilizzo di Evans. Ma penso che la risposta di Evans sia abbastanza chiara.

risposta data 07.11.2017 - 17:17
fonte

0

Il motivo per cui ogni accesso alle entità root o agli oggetti valore dovrebbe avvenire tramite l'aggregato è che la radice aggregata deve essere responsabile della gestione degli invarianti e assicurarsi che l'aggregato sia sempre in uno stato valido.

Nell'esempio del cliente, pensiamo a una regola aziendale relativa alle fatture. Diciamo che un cliente non può avere più di 10 fatture. Se si consente la creazione di fatture da diversi punti nell'app, sarà necessario verificare anche le regole aziendali. Questo può facilmente creare un gran casino quando le regole cambiano e c'è più di un posto in cui queste regole vengono controllate.

Potrebbe sembrare semplice e facile aggiungere un'entità dal servizio dell'applicazione, ma se ti aspetti che l'applicazione cresca e cambi, è sempre meglio applicare i principi DDD.

risposta data 07.11.2017 - 17:11
fonte

Leggi altre domande sui tag c# domain-driven-design design-patterns

Perché le funzioni di stato successivo e le funzioni di output di una funzione combinatoria di FSM? Transazione con servizi Web

score 2 · Accepted Answer

TLDR; "radice non aggregata" non è uguale a "componente di un altro aggregato"

La tua classe di fattura potrebbe non essere una radice aggregata, ma non perché è una componente del gruppo Cliente (o almeno non dovrebbe essere un componente). È (o dovrebbe essere) un oggetto dominio semplice, e quando è (attualmente) non un aggregato (root), allora perché non consiste di più di una classe e non consiste di altri componenti.

Solo perché esiste un'associazione 1: n tra i clienti e le fatture non rende automaticamente le fatture componenti di un cliente. Ovviamente hai i requisiti per gestire fatture come oggetti da solo, senza caricarle prima attraverso un repository clienti, ciò prova questo punto.

Quindi vedendo una fattura come un semplice oggetto di dominio, l'accesso a tale oggetto da qualche livello di servizio è abbastanza buono, anche da un punto di vista dei puristi DDD.