Suddenly every body and their little brother has been asking questions about this, that, or the other messaging pattern within a "Modular Monolith" architecture using Wolverine. That's honestly forced the Wolverine team to make some recent improvements and more in flight specifically to improve Wolverine's support for modular monoliths.
That work hopefully gets capped off with a big new tutorial that describes all of Wolverine's special sauce for modular monoliths while answering the most common questions users have about how to utilize Wolverine for common modular monolith hurdles.
- Isolating persistence per module, while still being able to use Wolverine transactional middleware and outboxes
- Eventual consistency between modules -- not saying that that's the thing you should do, but DDD folks seem to love the idea
- In process, asynchronous messaging between modules which Wolverine does probably as well as anything out there
- Tracing this stuff
- Automated testing support, especially when work crosses module boundaries
- Orchestration or choreography between logical modules. Like, what do you do if work has to be done in a certain order by different modules?
- Setting yourself up to move modules out later?
- Should you do this at all, which hopefully can be a more honest discussion of the very real technical challenges to doing modular monolith architectures which I feel is being brushed under the rug with all the hype there is right now for this approach
Using out-of-process, asynchronous messaging like RabbitMQ within your modular monolith to alleviate memory pressure, which also might tick the "Setting yourself up to move modules out later" part? Would also help folks with less experience with messaging. Last time I checked the Wolverine samples, the RabbitMQ ping pong thingy wasn't working, which I reported to Erik Shafer.