Il modo in cui descrivi i cambiamenti come operazioni aziendali viene spesso utilizzato con il sourcing di eventi, ma ovviamente non è necessario fare il sourcing di eventi per seguire il consiglio. La domanda quindi è perché vuoi usarla - hai intenzione di memorizzare una pista di controllo? O semplicemente non ti piace l'approccio Object- > DTO- > DB e preferiresti l'oggetto Changed- > [operations] - > DB?
La mia esperienza con questo concetto è che mentre suona molto bello e pulito, in pratica è davvero difficile da fare in modo significativo.
- O hai bisogno di un'intera serie di "pulsanti di modifica" (potresti organizzare il tuo ui leggermente diverso e nominare le cose in un altro modo, ma il concetto è lo stesso) per tutti i tipi di modi in cui potresti cambiare i dati. Per qualcosa di diverso dal più piccolo oggetto, non lo farai bene. Se fai questo, quindi salva la sequenza di operazioni (possibilmente compressa)
- O è necessario indovinare quale modifica è stata apportata e ciò non funzionerà se si desidera mapparlo alle operazioni aziendali. L'indirizzo è cambiato a causa di errori di ortografia o di spostamento della persona?
Ora, per me, questo significa che il tipo di interfaccia più comune, vale a dire "Voglio cambiare qualsiasi valore per questo oggetto", è una cattiva idea. L'unica cosa che puoi estrarre è il diff di due oggetti. Questo è ingombrante nella maggior parte delle lingue OO, ma può essere fatto.
Un suggerimento se segui quel percorso, sarebbe usare il modo in cui svn o git lo fa. Tieni traccia della versione con cui l'utente ha iniziato a lavorare, controlla quale versione è al momento del commit e poi confronta questi con la versione modificata. Se l'utente non è aggiornato, hai più opzioni; interrompere il commit o consentire il commit a determinate condizioni (deve essere scelto con l'esperto di dominio).
Quindi prendi il diff minimo e usalo; applicarlo nel database, memorizzarlo nel registro di controllo. (Questo è, naturalmente, approssimativamente ciò che gli ORM stanno facendo sull'oggetto originale.) Si ottiene un log riproducibile (in teoria), non si ha a che fare con un ampio set di operazioni e non si costringe gli utenti a usare estranei interfacce utente.
(Personalmente ho iniziato ad abbandonare le "tecniche DDD" per un approccio più orientato ai dati / valore. L'onere e la rigidità delle "tecniche DDD pure" appesantisce gran parte del codice, spesso con scarso guadagno oltre alla sensazione di fare qualcosa di giusto, dico "tecniche DDD", DDD come idea progettuale agnostica è ancora buona.)