modello di dominio anemico vs modello di dominio

Question

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

Se ho un modello di dominio e acquisisco i dati che devono essere mantenuti in un oggetto di trasferimento dati, questo rende il mio 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 catturare ciò che deve essere persistito in un modello di dominio viola le buone pratiche e crea l'anti-modello del modello di dominio anemico. Tuttavia, se si utilizza un DB relazionale non è possibile evitare di individuare la parte che crea 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 modello di dominio "reale" quando contiene tutto (o la maggior parte) del comportamento che costituisce il dominio aziendale (nota che sto sottolineando logica aziendale , non UI o altre preoccupazioni ortogonali).

Se stai usando la Lingua Ubiotica e ricevi feedback costante dai tuoi esperti di dominio , saprai che stai sulla strada giusta (gli esperti dovrebbero annuire quando vedono il tuo modello di dominio). Se non stai facendo queste cose, non stai facendo DDD ( Eric Evans ne parla ).

Sul punto dei DTO: non ignorarli. Dal punto di vista dell'implementazione, ti serviranno per trasportare i dati tra livelli / livelli. Il modo in cui combini DTO e veri oggetti di dominio dipende in realtà dalla tecnologia che stai utilizzando.

Come accennato in una risposta precedente, forse la tua attenzione ai dati e alla persistenza ti distrae dalla vera modellazione del dominio ...

Answer 2

Mi vengono in mente due elementi di interesse:

• Gli oggetti Data Transfer (DTO) sono diversi dagli oggetti dominio. Servono a scopi diversi in luoghi diversi in un'architettura - non confonderli. Gli oggetti di dominio forniscono una API ricca con elevata coesione . I DTO sono strutture di dati passivi utilizzati nell'interfaccia esterna di un'applicazione, in modo molto simile a UI ViewModels, ma rivolti a sistemi automatizzati anziché agli utenti.
• Sforzati di selezionare un ORM che ti consenta di utilizzare Ignoranza della persistenza . Ciò significa che puoi definire il tuo modello di dominio in modo illimitato e semplicemente fare in modo che l'ORM associ gli oggetti a un database relazionale.

Answer 3

  

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

Arrivare al modello di dominio mediante l'aggiunta di elementi in modo casuale è possibile, ma certamente non è una progettazione guidata dal dominio. (So ??che questo non è davvero utile. Tendo a pensare a me stesso molto incentrato sui dati, e in alcuni casi ci vuole uno sforzo reale per tirarsi da questo punto di vista.)