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!

  • 1
    I see a whole lot of architectural ceremony in your question, but does it solve any actual, real-world problems? The architecture you choose is going to be based on what you need, not how good it looks on paper, and you haven't said anything about what your application is actually supposed to accomplish. – Robert Harvey Dec 13 '17 at 17:25
  • I appreciate the perspective, but believe me that in this case it's warranted. This is the re-arch for a sprawling large scale feature rich ball-of-mud with a massive but messed up domain model, and we will have to enable multiple back ends and multiple front ends concurrently to get where we're going. I've done sufficient research and built enough similar systems to know we want DDD and Clean Architecture on this, just want to discuss nuts-and-bolts tactical patterns. Thanks though! – Iain Duncan Dec 13 '17 at 17:35
  • Unit of Work is orthogonal to Clean Architecture (You would put it wherever you're going to put your business logic). Did you have a specific question about that? – Robert Harvey Dec 13 '17 at 17:36
  • 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 -- Wouldn't that be your aggregate? – Robert Harvey Dec 13 '17 at 17:37
  • Yes, that is the question, is putting the unit of work handler in the Request Model and handing that to other service objects a good way to enable multiple repositories and use case interactors access to it? – Iain Duncan Dec 13 '17 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.