Come viene implementata la transazionalità nelle applicazioni DDD?

Question

Come viene implementata la transazionalità nelle applicazioni DDD?

#1 da (9 voti)

4

Ho cercato e letto recentemente su DDD e, finora, penso di averne compreso le basi.

Se ho capito bene, l'architettura è simile a questa:

Database <--SQL--> DAO/ORM <--CRUD--> Repository/Aggreagtes <--Business--> **¿?** <-- Controller --> Internet/Client/UI

Il mio dubbio gira attorno al divario ¿? . Di solito lo riempiono di servizi.

I miei servizi spesso sono la prima prova di un modello di dominio anemico , perché tutta la logica aziendale è a questi servizi (e le loro implementazioni sono abbastanza procedurali). Di conseguenza il mio modello di dominio è un semplice set di POJO.

La mia intenzione è di spostare gradualmente il mio attuale progetto verso un modello di dominio più ricco e un livello di servizio più sottile. Tuttavia, sono preoccupato per la transazione e il livello a cui appartiene.

Cercando come compilare il gap precedente, ho trovato questa domanda

Seguendo il link e la risposta verificata presumo che:

Ci sono ancora dei servizi in DDD. Questi servizi eseguono operazioni di business tramite repository (e root aggregati).
I servizi sono pensati per coprire le esigenze aziendali che non possono essere coperte attraverso root e / o repository agreggati.
I servizi eseguono transazioni commerciali tramite componenti UnitOfWork (UoW) . Una UoW potrebbe coinvolgere uno o più root e repository aggregati.

Domanda: È questo il modo di implementare il livello aziendale e la transazionalità in DDD? (App Service - > UoW - > Repository)

Se sì

[domanda bonus]: In che modo gli eventi e i gestori dell'applicazione si adattano a tale architettura? I servizi sono tradotti in gestori? (Gestore - > UoW - > Repository)?

Sono grato per qualsiasi tipo di input. Mi sento un po 'confuso con il modo in cui i livelli di ddd sono legati o come legarli con il minor accoppiamento possibile.

domain-driven-design layers transaction

posta Laiv 09.11.2016 - 23:58

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design layers transaction

I metodi di supporto possono essere sovrautilizzati? Perché abbiamo i metodi dei mutatori?

score 9 · Accepted Answer

A UoW might involve one ore more aggregated roots and repositories.

No, assolutamente no. Questo manca l'intero punto. Modifichiamo sempre un aggregato alla volta (uno per transazione).

Le transazioni sono in genere il coordinamento tra il componente dell'applicazione e il componente di persistenza. L'applicazione avvia una transazione (Uow, se lo desideri), legge l'aggregato di destinazione, modifica l'aggregato, lo salva e lo impegna.

Se il commit ha esito positivo, non vi sono state scritture in conflitto con quell'aggregato e il comando stesso ha avuto esito positivo. Se ci sono scritture in conflitto, il commit fallisce e il componente dell'applicazione riesce a capire la strategia di ripristino (unire, rieseguire il comando da un nuovo punto di partenza, segnalare un errore al chiamante, ecc.)

If I need to modify 2 aggregates in one transaction is probably caused by a bad design of aggregate roots.

Questo, o una mancata comprensione delle reali esigenze del business. È un modello relativamente comune assumere due cambiamenti che devono essere strettamente accoppiati quando il business case reale ha molta più flessibilità. Esempio classico: supponendo che il saldo del conto non debba mai scendere sotto lo zero, quando in realtà l'azienda è felice di maturare penalità di scoperto.