Modello di dominio anemico vs DDD per esempi di definizione?

1

Che cosa è un esempio di "Business Logic" che deve risiedere nel DomainModel vale a dire all'interno di un'entità invece che all'interno di un servizio (dominio), oltre a qualche logica di esempio che dovrebbe essere in un servizio.

Ecco cosa considererei casi abbastanza chiari (?):

La convalida di base verrebbe eseguita dagli attributi di definizione ViewModel e dalla convalida jQuery. Pertanto la correttezza dei dati dovrebbe andare bene al momento in cui i dati arrivano al Service / DomainModel (Entity).

Alcune logiche di business che dipendono da altre entità dovrebbero appartenere al di fuori dell'entità di un servizio (naturalmente / presumibilmente).

Qualcosa che potrei immaginare esistente in un DomainModel (Entity) sarebbe semplice aggiungere elementi a una proprietà di lista (assicurarsi che non esistano duplicati ecc.). Forse alcune funzionalità di base della copia.

Che altro inserisci in Entity / DomainModel, invece del servizio? È difficile fare una chiara distinzione, o almeno sembra che la maggior parte della logica finisca nei Servizi.

    
posta lko 28.05.2013 - 12:23
fonte

2 risposte

3

Ci sono state diverse discussioni su tutto questo.

Dai un'occhiata a questa domanda SE dove Iulian Margarintescu ha detto qualcosa di piuttosto interessante:

[...] the anemic domain model is not by itself an anti-pattern, only when you try to do DDD and end up with and anemic model.

Ha menzionato questo interessante articolo .

Dalla mia esperienza personale, quando lavoro con EF POCO (Anemic Domain Model) generato, tendo a mettere le mie regole aziendali in specifiche . In questo modo sono in grado di scrivere regole di business per qualsiasi mia entità di dominio e concatenarle durante l'interrogazione.

Modifica

Se vuoi seguire rigorosamente il DDD, leggi questo . Eric Evans sta descrivendo quale dovrebbe essere esattamente il ruolo di un servizio e cosa dovrebbe essere messo in esso.

    
risposta data 28.05.2013 - 14:25
fonte
1

Il modello di dominio è di solito (e presumo nel tuo caso in realtà) un normale modello di oggetti. Quindi le stesse regole e pratiche si applicano alla modellazione di domini come per la modellazione di oggetti. Quindi guarderei SOLID , KISS e vari schemi di progettazione .

    
risposta data 28.05.2013 - 13:30
fonte

Leggi altre domande sui tag