Perché un'architettura con modelli anemici è conforme allo standard JavaEE?

Vedo anche questo nel mondo .NET e finora ho identificato una serie di motivi sul perché questo accada (anche io non preferisco i modelli anemici di dati).

1. Vecchio codice. Le persone non conoscevano meglio ed è troppo costoso da riscrivere.
2. Interpretazione errata del principio DRY. Le persone vogliono usare i loro oggetti come contratti e inviarli via cavo come XML / JSON e quindi preferiscono trasformarli in semplici DTO - e invece di usarli come contratti e poi tradurli in oggetti di dominio reale ai confini le persone vanno al modello antipatico anemico invece di non avere due oggetti che rappresentano lo stesso oggetto.
3. L'applicazione non è in realtà abbastanza complessa da giustificare un modello di dominio.

Ora, in 1 e 3 un modello di dominio anemico potrebbe effettivamente essere la scelta giusta. Avere un modello di dominio ricco può essere un lavoro che potrebbe non fornire un valore sufficiente data la tua applicazione. Molte applicazioni, anche nel mondo JavaEE, sono solo glorificati livelli CRUD in cima a un database. Se la logica del dominio non è sufficiente, i modelli di dominio anemico possono effettivamente essere la scelta corretta.

In 2 tuttavia direi che sono solo cattive pratiche. Se hai un'applicazione con un dominio sufficientemente ricco da giustificare un modello di dominio, dovresti averne uno. In base all'SRP, ogni oggetto dovrebbe avere una singola responsabilità, le progettazioni DTO hanno già una responsabilità - rappresentano il formato di trasferimento dei dati tra il sistema e un sistema esterno. Non dovresti usarli per nient'altro. Ci dovrebbe essere un livello di mappatura (che in questi giorni è molto più veloce da scrivere di quanto lo sia mai stato prima dato che ci sono un sacco di framework / librerie che possono rimuovere un sacco di lavoro per scrivere questi) che mappano dal DTO al tuo oggetti di dominio e viceversa - e quindi la tua applicazione dovrebbe utilizzare solo questi oggetti di dominio per eseguire lo scopo previsto. Questo ti dà anche la possibilità di refactoring e modificare la tua implementazione indipendentemente dal cambiamento del tuo contratto esterno - e questo è un enorme guadagno una volta che sei in produzione.

Ma si. Può essere un lavoro extra, e la parte davvero difficile riguarda il tuo dominio e la domanda "Questo dominio è motivato ad andare su DDD?". E non dovresti davvero sottovalutare questa domanda, in realtà è davvero difficile.

In genere gli oggetti del dominio attraversano i livelli e anche i confini del processo. Quindi gli oggetti Dominio che sono in genere POJO sono essenzialmente il contratto tra livelli e processi. I contratti dovrebbero definire la struttura prevista degli input, degli output (e delle eccezioni) e non della logica aziendale. Questo è il tempo reale che stai scrivendo codice aziendale o altro.

Mantenere i domini leggeri e nudi assicura che la conversione (serializzazioni in varie forme) avvenga facilmente. Ecco un esempio: il tuo dominio viene distribuito da Jersy Clients come oggetto JSON - ora se l'oggetto ha un sacco di BL e dipendenze - la conversione o la serializzazione su JSON sarà complicata e la conoscenza indesiderata verrà passata al client che si preoccupa solo dei dati.

Questo non vuol dire che i tuoi oggetti devono essere stupidi! Se è possibile ridurre la ridondanza nell'oggetto fornendo un campo con alcuni metodi getter aggiuntivi per comodità, procedere in ogni modo e farlo - ad esempio se si dispone di campi di costo e quantità unitari nel POJO ma per la visualizzazione in genere è necessario il prezzo totale avanti e aggiungilo come getter senza introdurre nuovi campi (ridondanti) - assicurati di non fornire alcun metodo setter solo per il getter. questo tipo di linee di confine con BL, ma non lo è se il ruolo dei tuoi servizi è molto più complicato del prezzo di calcolo.

Questo non significa che le applicazioni J2EE siano basate su modelli skimpy, ma solo che puoi implementare qualsiasi modello più complesso usando solo entità, attributi e relazioni.

Allo stesso modo puoi implementare qualsiasi struttura di controllo (per ciascuno, mentre, fare fino a) usando solo se e goto.

Non è necessario che i concetti più sofisticati facciano parte dell'implementazione.

Il vero problema è che mentre DDD può sembrare bello su un diagramma, nessuno ha trovato un modo elegante per tradurre questi concetti in codice.

Ero un grande fan della generazione di codice dai modelli, ma ora ho molti dubbi. Il modello è ora il codice sorgente, che deve essere sotto il controllo dell'implementatore / programmatore se si desidera che il sistema funzioni e funzioni bene, tuttavia, i progettisti e i modellatori sono abituati a hackerare il modello e tradizionalmente non si preoccupano di alcuna implementazione problemi. In effetti il modello che era uno strumento di comunicazione e l'interfaccia tra designer e sviluppatori è diventato un campo di battaglia tra i progettisti che vogliono una descrizione elegante e accurata delle esigenze e gli sviluppatori che hanno bisogno di un modello preciso e spesso abbastanza brutto per generare efficienza codice.