DDD con ORM dove dovrebbe andare la logica aziendale?

so it would have been impossible to switch out to another ORM (not that we wanted to)).

Questo sembra sbagliato. Uno dei principali vantaggi del modello di repository è che si nasconde la logica di accesso ai dati e che è facilmente intercambiabile.

So far it feels as though I put my business logic in my domain model and via repositories I would work with the ORM (which ever I chose). However, if I wanted to continue to use the MDA tool for the ORM part of the application, the model created here would be very anemic (i.e not contain any business logic). Similarly if I used Entity framework (.net) or NHibernate for my ORM it too would be an anemic model.? I am not sure where you would put the business logic if I just used NHibernate.

Un modello di dominio anemico è considerato una cattiva pratica da molti, ad esempio da Martin Fowler. Dovresti evitare questo tipo di design perché un tale modello porta a tecniche di progettazione procedurale piuttosto che a una buona progettazione orientata agli oggetti. Quindi hai classi di dati e classi di gestione / gestione che significano stato e comportamento separati. Ma un oggetto dovrebbe davvero essere "stato e comportamento".

NHibernate fa un ottimo lavoro con l'ignoranza della persistenza. È possibile nascondere i dettagli della mappatura in XML o con FluentNHibernate e scrivere semplicemente POCO. È molto facile creare un modello di dominio ricco con NHibernate. Penso che tu possa farlo anche con l'entity framework e lo strumento MDA. Finché questo strumento produce classi parziali puoi estendere il codice generato abbastanza facilmente senza dovervi preoccupare che una nuova generazione possa distruggere il vostro codice scritto dall'utente.

Per farla breve. Quando usi NHibernate, niente, ripeto niente , ti impedisce di abbracciare un modello di dominio ricco. Consiglio di usarlo con FluentNHibernate e mappare a mano. Il codice di mappatura richiede solo da 5 a 10 minuti per scrivere. Suppongo che lo stesso sia vero per il framework di entità e che i suoi strumenti almeno creino classi parziali facilmente estendibili.

Am I correct in thinking this way, in other words with DDD all the business logic in the domain and just use the ORM for persistence via repositories?

Per la maggior parte sei corretto. Dovresti avere un modello di dominio ricco. Soprattutto quando le cose diventano sempre più complesse, è più facile da mantenere ed estendere quando lo hai progettato correttamente. Ma tieni presente che DDD conosce anche i servizi (Domain Layer e Application Layer) per implementare la logica di business e le Factory per incapsulare la logica creazionale.

Tendo anche a differenziare la logica aziendale in logica di dominio e logica di business dell'applicazione reale. La logica del dominio è il modo in cui il dominio interagisce e si comporta mentre la logica dell'applicazione, che è un livello completamente diverso, incapsula il modo in cui il dominio viene utilizzato per il caso / l'applicazione specifici. Spesso devo aggiornare il modello di dominio per supportare casi d'uso specifici e renderlo più potente.

However, if I wanted to continue to use the MDA tool for the ORM part of the application, the model created here would be very anemic (i.e not contain any business logic).

Non so quale strumento MDA stai usando, ma quelli con cui ho lavorato creano sempre classi parziali, quindi sei libero di completarle con la stessa logica di business che desideri.

Tuttavia, ritengo che gli strumenti MDA siano un po 'meno appropriati in un contesto DDD rispetto agli ORM, perché la generazione del codice spesso tende a produrre classi confuse con il rumore specifico degli strumenti invece delle entità di dominio semplificate e chiaramente espresse che ci aspettiamo . In realtà, ciò che ottieni spesso è un mix di dati di dominio, logica di persistenza, logica di validazione dei vincoli ... e non so se c'è un modo per separare questi dubbi con la maggior parte degli strumenti MDA.

E ovviamente, non puoi toccare il codice generato se non attraverso le classi parziali, il che significa che non puoi eliminare il potenziale comportamento anti-DDD che sarebbe integrato. Questo è problematico in un approccio in cui si vogliono applicare rigide barriere tra Aggregates e adattare perfettamente le relazioni tra le entità. Costruire il tempo in un ambiente di integrazione continua può anche risentire del passaggio di generazione del codice aggiuntivo.

A parte questo, penso che Falcon abbia praticamente detto tutto - assolutamente nulla negli strumenti ORM o MDA ti impedisce di avere entità di dominio complete.

Quello che faccio nel mio team è quello di modellare il mio oggetto, dominio e aggiungere la mia logica di business allo stesso tempo. Non utilizzo Model Driven Development che genera un codice da un modello ma preferisco l'approccio di annotazione. Intendo dire che a livello di oggetto all'interno del diagramma di classe aggiungo gli stereotipi ORM. Questo aggiungerà annotazioni di persistenza direttamente nel codice che sono compatibili con EJB3 / hibernate. La creazione del database viene eseguita da Hibernate e certamente non dai modelli UML. Questo è molto meglio perché se il codice cambia e le annotazioni aggiunte non sono esattamente ciò che lo specialista di ibernazione, allora lui / lei può cambiarlo, ma il modello è ancora buono. Posso anche modificare i miei requisiti e il mio modello di dominio è ancora ok.

Gli sviluppatori possono aggiungere la logica di business all'interno di ogni metodo e aggiungere un commento, posso anche modellare e aggiungere vincoli. Ad esempio, le vendite dovrebbero essere superiori a 50k se non ecc .... Non è necessario codificarlo ma solo scrivere nel modello e queste informazioni dovrebbero essere visibili al team di sviluppo. UML davvero interessante e flessibile.