Sto rearchitecting un sistema in Python, usando SQLAlchemy per il livello di mappatura dei dati, e l'architettura dei componenti di Zope per l'iniezione delle dipendenze e la dichiarazione dell'interfaccia. Sono in procinto di capire come combinare (o attingere) DDD, DCI e l'architettura Clean / Onion / Hexagonal. In SQLAlchemy, abbiamo un'unità di implementazione del lavoro che voglio appoggiare. Ho realizzato interfacce per tutto, in modo che tutti i livelli accedano rigorosamente alle implementazioni concrete di altri oggetti tramite la ricerca DI basata su interfacce interne. Questa parte funziona bene, le entità principali sono definite nel loro pacchetto e SQLAlchemy esegue su di esse un mapper. La mia domanda è come gestire l'oggetto della sessione SLQAlchemy, al quale aggiungiamo tutti gli oggetti modificati per ottenere un commit tutto o niente.
Mi sto appoggiando al design che:
-
Un RequestModel viene creato da un RequestModelFactory, che viene recuperato tramite la ricerca DI di un'interfaccia IRequestModelFactory. L'interfaccia non conosce nulla sul Web o SQLA, ma contiene una raccolta .session e un metodo .commit (). L'implementazione concreta di questo è registrata in main, ed è un SQLAlchemyRequestModel con le implementazioni concrete di SQLA di session e commit
-
i repository e UseCase / Interactors funzionano con un oggetto RequestModel, conoscono solo i metodi dell'interfaccia, quindi usano la raccolta .session e chiamano il metodo .commit e funzioneranno bene se un'implementazione concreta alternativa di RequestModelFactory è registrato (per test o backend alternativi). Possono farlo perché sono paralleli all'interfaccia IRequestModel, quindi conoscono .commit e .session, ma solo che questa è una raccolta di oggetti modificati e modo per attivare un commit.
-
Nell'app Web, il controller Web (o altro bit) renderà RequestModel dai dati in arrivo, ottiene un repository e / o un Interact di UseCase tramite la ricerca DI, quindi chiama i metodi sul repository o UseCase, passando nel RequestModel come parametro in modo che UseCase possa ancora fare unità di lavoro. In alternativa, è possibile accedere ai repository e ai UseCases tramite un adattatore che consente loro l'accesso al RequestModel
Credo che questo si adatti abbastanza bene ai principi di Clean Architecture e DDD, ma volevo chiedere se questo va bene agli architetti più esperti, e in caso contrario, quali altre opzioni sono per lavorare con i repository e gli UseCases in cui vogliamo consegnarli un'unità di gestore del lavoro. Quello che voglio assicurarmi di raggiungere è che se un Interact di UseCase utilizza più repository, esiste ancora un oggetto centrale per il commit di tutto e quindi gli UseCases non violano alcuna regola di dipendenza. Pensieri benvenuti!