modello di dominio anemico rispetto al modello di dominio

Question

Essere di nuovo confuso dopo aver letto di questo anti-pattern e le molte preoccupazioni su di esso qui su SO.

Se si dispone di un modello di dominio e si acquisiscono i dati che devono essere persistenti in un oggetto di trasferimento dati, ciò rende il modello di dominio un wrapper attorno ai dati? In tal caso, utilizzerei un modello di dominio anemico. Ma se aggiungo abbastanza logica di dominio su quel wrapper, a che punto diventa un vero modello di dominio, allora?

Ho l'impressione che l'acquisizione di ciò che deve essere mantenuto in un modello di dominio vìoli le buone pratiche e crea l'anti-pattern del modello di dominio anemico. Tuttavia, se si utilizza un DB relazionale, non è possibile evitare di individuare la parte che rende lo stato dell'oggetto e salvarlo.

Dato che sono piuttosto confuso riguardo ai concetti, non sono sicuro che ciò che scrivo abbia senso. Sentiti libero di chiedere chiarimenti.

Answer 1

diventa un 'vero e proprio' modello di dominio quando contiene tutto (o quasi) del comportamento che compone il dominio aziendale (nota sto sottolineando affari logica, senza interfaccia utente o altro preoccupazioni ortogonali).

Se si sta utilizzando il Ubiquitous lingua, e ottenere feedback costante dai vostriesperti del settore, saprete che siete sulla strada giusta (esperti dovrebbero annuire quando vedono il vostro modello di dominio). Se non stai facendo queste cose, non stai facendo DDD (Eric Evans speak about it).

Sul punto di DTO: non ignorarli. Dal punto di vista dell'implementazione, ti serviranno per traghettare i dati tra livelli/livelli. Il modo in cui combini DTO e veri Oggetti Dominio dipende molto dalla tecnologia che stai utilizzando.

Come accennato in una precedente risposta, forse la vostra attenzione su dati e persistenza è si distrae dal vero modellazione dominio ...

Answer 2

Ma se aggiungo abbastanza logica di dominio su quel wrapper, a che punto diventa un vero modello di dominio, allora?

L'arrivo al modello di dominio mediante l'aggiunta di elementi in modo casuale è possibile, ma certamente non è un design basato su domini. (So ​​che questo non è molto utile io tendo a pensare molto ai dati stessi, e in alcuni casi ci vuole uno sforzo reale per tirarmi fuori da questo punto di vista.)

Answer 3

Due elementi di interesse mi vengono in mente:

• Gli oggetti di trasferimento dati (DTO) sono diversi dagli oggetti dominio. Servono a scopi diversi in luoghi diversi in un'architettura - non confonderli. Domain Objects fornisce un'API ricca con ad alta coesione. Le DTO sono strutture dati passive utilizzate nell'interfaccia esterna di un'applicazione, proprio come l'UI ViewModels, ma destinate ai sistemi automatici anziché agli utenti.
• Sforzati dopo aver selezionato un ORM che ti permetta di impiegare Persistenza Ignoranza. Ciò significa che è possibile definire il modello di dominio in modo illimitato e semplicemente fare in modo che ORM mappi gli oggetti su un database relazionale.