Shared DbContext and Transaction Across Handlers in Wolverine Within a Single Request Scope in a Modular Monolith .NET Application

[ensstc]

Hello, I want to develop a modular monolith .NET application. My main goal is to ensure that all modules in the project do not reference each other directly and that each module works with its own DbContext object.

While modules use different DbContext objects, I want to proceed by sharing a common connection and transaction (wrapping the entire request lifetime with an in-memory transaction, without using outbox or inbox patterns). For this purpose, I defined a Wolverine DbContext object globally and aim to pass its connection and transaction to other modules.

My problem is this: the “Wolverine DbContext” object I obtain in the handler of Module 1 is different from the “Wolverine DbContext” object I obtain in the handler of Module 2 (even though it is registered as scoped). I assume that Wolverine creates a new DI scope for each handler, which causes the object to be recreated.

Is it possible to use the same scope throughout the request lifetime so that all handler calls can share common dependencies? If yes, how can I achieve this?

Thank you.

[jeremydmiller]

Nope, nope, nope. Sorry, I want absolutely nothing to do with that!

"I assume that Wolverine creates a new DI scope for each handler, which causes the object to be recreated" -- yikes, no, not sure where you got that from.

My consistent advice in anything like this is:

• You should never need to have a transaction that spans multiple DbContext objects
• So either change your DbContext boundaries because they're wrong, or...
• use eventual consistency between modules if you must.

I'm converting this to a discussion in case someone else has something better to add.

[bytemaestro]

I'd like to add that with the Modular Monolith design we are using (w/ Clean Architecture, DDD), on a single SQL server database__, we use one DbContext per "module" (bounded context). Now for one module to get a data from another module, we use read-only views instead of creating a projection that writes to a new table, duplicating data via eventual consistency; e.g. Customer module and Employee module with EC, Customer may keep a projection from the Employee module to show their best Salesperson.. so it will write a new record in a "projection/read model" table called dbo.SalesPersonLookup ( EmployeeId, Firstname, lastname) whenever the EmployeeCreated domain event gets raised... So instead of doing that, we have a shared view in our CustomerDbContext that reads those columns from the dbo.Employee table (seperate DbContext and module).. so the transactions are cross Db, however the Customer module will never write into another module's dbContext/table..., so the transactions really are not helping this way, but we have a milddleware that does work with the EC event implementation...

Where the CrossDbContext transaction middleware work:

1. Command: Create a new Employee,
2. Handler: .Add(new Employee)
3. Handler: employeeDbContext.SaveChanges()
4. Repository/UnitOfWork: Publish EmployeeCreated event
5. Customer module (BC) listens for EmployeeCreated
6. Handler: EmployeeCreatedEventHandler
7. CustomerDbContext: SaveChanges()
8. If an error anywhere , our custom wolverine transaction middle covers both writes and rolls back all db writes.