Let the application service call both methods
Il servizio di applicazione 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 le basi per l'esecuzione del comportamento del dominio e in quanto tale fornisce tutte le dipendenze richieste. Tuttavia, quando possibile, dovrebbe delegare il comportamento al modello di dominio.
Use method injection/double dispatch to inject the domain service into
the entity, letting the entity do it's thing and then let it call the
method of the domain service (or the other way around, letting the
domain service call the method on the entity)
Questo è un approccio migliore perché più del comportamento è delegato all'entità o al servizio di dominio. Il modo più disaccoppiato per implementare questo è avere un'entità che esprima una dipendenza da un servizio come parametro del metodo che fornisce il comportamento in questione.
Raise a domain event in the entity method, a handler of which calls
the domain service.
Il pattern degli eventi di dominio, come spiegato da Udi e anche da Evans stesso, è abbastanza versatile e può essere applicato in una varietà di scenari. Tuttavia ci sono alcune complicazioni che ne derivano. Innanzitutto, devi assicurarti di avere un ambito appropriato all'interno del publisher di eventi del dominio. La maggior parte delle volte, i gestori di eventi del dominio avranno dipendenze e se si sta utilizzando un contenitore IoC, è necessario assicurarsi che vengano iniettate istanze appropriate. Ad esempio, in un'applicazione Web, l'attributo [ThreadStatic] è 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 al 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 queste basi sono coperte, 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 vuoi invocare comportamenti aggiuntivi in risposta a un evento, che è al passato . Questo è un vincolo importante, poiché il gestore di eventi del dominio non può influenzare il comportamento dell'entità. D'altra parte, con l'approccio 2, il servizio iniettato ha il potenziale per influenzare il comportamento perché è dichiarato una dipendenza per quel particolare comportamento.