Quali problemi trovi con questa vista sulla progettazione basata sul dominio?

Question

Ho appena scritto un lungo (e disordinato) blogpost sulla mia vista sul design basato su domini al giorno d'oggi, con strutture come la primavera e l'ibernazione in uso in modo massiccio.

Ti chiederei di individuare eventuali problemi con le mie opinioni in merito - perché questo non funzionerà, perché non sta dando i vantaggi del DDD, perché non è una buona idea in generale.

The blogpost is here (Non penso di doverlo copiare e incollare su SO - se pensi che dovrei, dimmelo).

So che la domanda è soggettiva, ma è mirata a raccogliere le opinioni più predominanti.

(che sto Tagging Java, dal momento che i quadri sono discussi framework Java)

Answer 1

Ho appena trascorso un anno della mia vita lacerando un'applicazione per eliminare un dominio anti-modello anemico e il suo uso improprio di Hibernate.

Posso dire senza alcun dubbio che il codice che deriva dal DDD è molto più facile da capire e da refactoring. Nel nostro caso, la rimozione di una miriade di getters non necessari & setter, l'aumento dell'incapsulamento, la concentrazione della logica di business e la conseguente (drammatica) semplificazione dei livelli di servizi associati a DDD hanno reso il sistema molto più facile da mantenere che ora credo che saremo in grado di finirlo, mentre prima si stava trascinando per sempre. Abbiamo ridotto il numero di righe di questa applicazione del 50% senza rimuovere alcuna funzionalità.

Credo anche che l'intero punto di uno strumento ORM è così che la mia logica di business è ordinato con il codice di persistenza. Quando disponevamo di un modello di dominio anemico, disponevamo di un DAO per ogni classe di dominio, ora disponiamo di un piccolo numero di DAO come punto di ingresso per CRUD nelle classi di dominio "principali", ma le altre classi di dominio "minori" vengono gestite da i loro genitori ... non perché la logica di persistenza si trova nel genitore, ma perché Hibernate reagisce in modo trasparente alla logica del business e rende tutto Just Work.

In breve, non posso rispondere a questa domanda SO perché ho decisamente d'accordo con il tuo post al 100% ... e sto vivendo ogni giorno.

Answer 2

Andiamo con l'approccio "modello anemica", in modo da poter riutilizzare gli stessi modelli con la logica di business diverso. Tuttavia, includiamo calcoli e metodi di supporto all'interno dei nostri modelli se sono applicabili a tutti i casi. Ma non iniettiamo nulla nei nostri modelli e non iniettiamo i nostri modelli in IoC.

Answer 3

Personalmente non sono convinto che la parte che riguarda l'iniezione di repository di oggetti nel oggetti di dominio (ovvero le entità persistenti) è necessario con la primavera e Hibernate. Hibernate sta già fornendo collezioni persistenti che possono eseguire il caricamento lento, quindi hai già la possibilità di attraversare il modello di dominio in un modo che separa l'infrastruttura di accesso ai dati dalla logica aziendale. Non vedo cosa aggiunga il repository di valori nel repository sul modello di dominio.

MODIFICA: Oops, pubblicato prima di leggere l'intero articolo. Ora che ho letto l'intero post del blog, penso di essere d'accordo. Mi piace la parte che consiglia di fare senza DTO laddove possibile.