DDD + POCO ha senso?

POCO sta per semplici vecchi oggetti c #. Viene dall'equivalente java POJO . È solo un nome alla moda per mostrare al mondo che non tutto deve essere una classe derivata. I POCO non sono necessariamente DTO, possono essere oggetti in piena regola con POCO di stato e di stato, mentre i DTO hanno solo lo stato.

Ora parla del tuo dominio - se come dici tu stai provando a fare DDD ma le tue entità non hanno un comportamento rispetto a te che sei stato morso dal modello anemico del modello di dominio anti-pattern. Prendi il libro di Mr. Evans su Domain Driven Design e dopo averlo letto inizia a pianificare il refactoring del tuo modello, preferibilmente con il tuo esperto di dominio.

Vale anche la pena ricordare che il modello di dominio anemico non è di per sé un anti-modello, solo quando si prova a fare DDD e si finisce con un modello anemico. Quindi, se le tue app stanno andando bene e gli utenti sono felici, non preoccuparti del refactoring per il DDD, tienilo a mente per il futuro.

Questo link potrebbe aiutarti a identificare altri problemi

Se le entità principali sono semplici DTO, allora potrebbe essere considerato un modello di dominio anemico .

Non mi è mai piaciuta l'idea di spostare la logica sui servizi: sembra una stampella per sistemare la brutta architettura di persistenza .

POCO e DTO sono due cose diverse. Gli esperti di DDD hanno utilizzato POCO per differenziarsi dal modello EntityFramework iniziale in cui le Entità dovevano estendere EntityObject o implementare un'interfaccia specifica. A partire da 4.1 Entity Framework supporta anche POCO per la persistenza che consente un comportamento più ricco e un approccio più incentrato sul dominio per lo sviluppo dei propri oggetti di business. I DTO sono semplici oggetti dati stupidi che non hanno un comportamento (di solito per il trasferimento tra due livelli di un'applicazione).

Personalmente, non uso più DTO a tutti, quando la mia interfaccia utente comunica con il livello aziendale, mi aspetto che i Modelli di Vista abbiano una logica di interazione incorporata in essi insieme ai dati. Questo approccio funziona con le applicazioni ASP.NET MVC e con i client Rich / Smart che accedono a servizi di riposo sul web. Dietro il livello di servizio, le query del client vengono tradotte da entità di dominio in VM e i comandi in entrata vengono tradotti in azioni contro il dominio. In questo modo il cliente è protetto dai dettagli / dalle intrusioni del Dominio e il Dominio non è corrotto da preoccupazioni del cliente / display.