Durante la lettura di "Pattern, principi e pratiche del Domain-Driven Design" di Nick Tune; Scott Millett (certamente non il primo libro su DDD che ho letto) Ho iniziato a capire l'utilizzo dei pattern EAA di Martin Fowler con DDD e con che è arrivata una domanda.
Un singolo modello SQLAlchemy è come Active Record (se ho capito bene), tuttavia, un insieme di modelli SQLAlchemy è molto bravo a sottrarre il meccanismo di persistenza, quindi ho sempre pensato al seguente modello di dominio , degradando in alcuni punti il modello di dominio anemico.
In molti casi ci sono ancora Transaction Scripts , che toccano diverse Entità. Sto cercando di mantenerli in azioni / servizi (Service Layer?) Perché è sbagliato avere azioni che toccano più modelli nelle stesse classi del modello (possono verificarsi dipendenze circolari) a meno che non siano subordinate (giacciano più in basso nella struttura aggregata). / p>
Il risultato non è un modello puro (poiché la logica aziendale è tra "azioni" e "record attivi") - più simile a un qualche tipo di ibrido di quelli menzionati sopra - ma funziona in pratica, acquisisce conoscenza del dominio (sia verbi e nomi) bene, si adatta naturalmente alla persistenza di SQLAlchemy.
Quale modello i modelli SQLAlchemy (in modalità ORM) rappresentano naturalmente e in che modo le operazioni, che toccano diversi modelli, possono essere adattate al modo DDD? C'è qualcosa che posso migliorare su quanto descritto sopra?
Per chiarire di più, questo domanda e le sue risposte si occupa di un altro dilemma simile nello spirito: se utilizzare le classi ORM direttamente per il modello di dominio o aggiungere un altro livello (e la risposta preferita non è l'overarchitect).
In questa domanda, sto cercando di trovare un buon modo per posizionare comportamenti multi-entità. La mia opinione è che i moduli "azione" / "servizio" con funzione per azione siano il posto giusto (in Python è usuale usare le funzioni a livello di modulo quando non c'è uno stato condiviso).