Come scegliere se utilizzare un evento di dominio o consentire al livello applicazione di orchestrare tutto

Sto impostando i miei primi passi nella progettazione guidata dal dominio, ho comprato il libro blu e tutto il resto e mi ritrovo a vedere tre modi per implementare una determinata soluzione. Per la cronaca: non sto usando CQRS o Event Sourcing.

Supponiamo che una richiesta dell'utente arrivi nel livello di servizio dell'applicazione. La logica aziendale per quella richiesta è (per qualsiasi motivo) separata in un metodo su un'entità e un metodo su un servizio di dominio. Come devo fare per chiamare quei metodi?

Le opzioni che ho raccolto finora sono:

• Consentire al servizio dell'applicazione di chiamare entrambi i metodi
• Usa il metodo injection / double dispatch per iniettare il servizio di dominio nell'entità, lasciando che l'entità faccia il suo dovere e poi lascia che chiami il metodo del servizio di dominio (o viceversa, lasciando che il servizio di dominio chiami il metodo sull'entità)
• Genera un evento di dominio nel metodo entità, un gestore del quale chiama il servizio di dominio. (Il tipo di eventi di dominio di cui sto parlando sono: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )

Penso che siano tutti fattibili, ma non sono in grado di scegliere tra di loro. Ci sto pensando da molto tempo e sono arrivato a un punto in cui non vedo più le differenze semantiche tra i tre. Conoscete alcune linee guida su quando usare cosa?

Consentire al servizio dell'applicazione di chiamare entrambi i metodi

Il servizio applicativo di solito è un ottimo punto di partenza per questo, tuttavia dovresti sempre cercare di spostare il comportamento il più vicino possibile all'entità. Il servizio applicativo svolge un ruolo di orchestrazione e imposta la fase per l'esecuzione del comportamento del dominio e come tale fornisce tutte le dipendenze richieste. Tuttavia, quando possibile, dovrebbe delegare il comportamento al modello di dominio.

Usa il metodo injection / double dispatch per iniettare il servizio di dominio nell'entità, lasciando che l'entità faccia il suo dovere e poi lascia che chiami il metodo del servizio di dominio (o viceversa, lasciando che il servizio di dominio chiami il metodo sull'entità)

Questo è un approccio migliore perché gran parte del comportamento è delegato all'entità o al servizio di dominio. Il modo più disaccoppiato per implementare questo è far sì che un'entità esprima una dipendenza da un servizio è come un parametro del metodo che fornisce il comportamento attuale.

Genera un evento di dominio nel metodo entità, un gestore del quale chiama il servizio di dominio.

Il modello di eventi del dominio, come spiegato da Udi e anche dallo stesso Evans, è piuttosto versatile e può essere applicato in una varietà di scenari. Vi sono tuttavia alcune complicazioni. Innanzitutto, devi assicurarti di avere l'ambito corretto all'interno del publisher di eventi di dominio. Il più delle volte, i gestori di eventi di dominio avranno dipendenze e se si utilizza un contenitore IoC, è necessario assicurarsi che vengano iniettate le istanze appropriate. Ad esempio, in un'applicazione Web, il[ThreadStatic]l'attributo è problematico per l'ambito. Un'altra complessità è quella dei confini trascrizionali. Devi prendere in considerazione le transazioni, perché se un'entità genera un evento di dominio, ma un successivo commit nel database fallisce, tutti i gestori di eventi di dominio avranno bisogno di un modo per eseguire il rollback, altrimenti finirai per generare un evento non valido. Se tuttavia hai coperto queste basi, gli eventi di dominio sono un ottimo modello per incapsulare la logica di dominio all'interno delle entità stesse.

La differenza tra l'approccio 2 e 3 dipende dal caso d'uso. Un evento di dominio si applica quando si desidera invocare comportamenti aggiuntivi in ​​risposta a un evento, che è passato . Questo è un vincolo importante, poiché il gestore di eventi di dominio non può influire sul comportamento dell'entità. D'altra parte, con l'approccio 2, il servizio iniettato ha il potenziale di influenzare il comportamento perché è dichiarato una dipendenza per quel particolare comportamento.