I'm rearchitecting a system in Python, using SQLAlchemy for the data mapping layer, and the Zope Component Architecture for dependency injection and interface declaration. I am in the process of figuring how to combine (or draw on) DDD, DCI, and the Clean/Onion/Hexagonal architecture. In SQLAlchemy, we have a unit of work implementation that I want to lean on. I've made interfaces for everything so that all layers strictly access concrete implementations of other objects through DI lookup based on inner interfaces. This part is working nicely, core entities are defined in their package, and SQLAlchemy runs a mapper over those. My question is how to deal with the SLQAlchemy session object, which we add all changed objects to in order to get an all-or-nothing commit.
I'm leaning to the design that:
A RequestModel is created from a RequestModelFactory, which is retrieved through DI lookup of a IRequestModelFactory interface. The interface knows nothing about the web or SQLA, but contains a .session collection and a .commit() method. The concrete implementation of this is registered in main, and is an SQLAlchemyRequestModel with the SQLA concrete implementations of session and commit
the Repositories and UseCase/Interactors work with a RequestModel object, they only know about the interface methods, so they use it's .session collection and call it's .commit method, and will work fine if an alternate concrete implementation of the RequestModelFactory is registered (for testing or alternate backends). They can do this because they are parallel to the IRequestModel interface, so they know about .commit and .session, but only that this is a collection of changed objects and way to trigger a commit.
In the web app, the web controller (or other bit) will make the RequestModel from incoming data, get a Repository and/or UseCase Interactor via DI lookup, and then call methods on the Repository or UseCase, passing in the RequestModel as a param so that the UseCase can still do unit of work stuff. Alternately, the Repositories and UseCases could be accessed through an adapter that gives them access to the RequestModel
I believe this fits the principles of Clean Architecture and DDD fairly well, but wanted to ask if this looks good to more experienced architects, and if not, what other options are for working with Repositories and UseCases where we want to hand them a unit of work handler. What I want to ensure I achieve is that if a UseCase Interactor uses multiple repositories, that there is still one central object for committing everything, and then the UseCases don't violate any dependency rules. Thoughts welcome!