In a microservice, is the transactional boundary the bounded context or the aggregate?

Question

May be the first question should be: what would help me decide whether my Microservice should contain an entire bounded context possibly with several aggregates, or should it rather contain only one aggregate?

If the Microservice contains several aggregates, then another question rises in my mind: shall the Microservice have several transactional boundaries (one per aggregate) or shall the Microservice have only one transaction boundary (the bounded context)?

Maybe, the answer to these questions is: it depends. But I'd like to have some rationale to make the right decisions.

I've tried to implement an experimental Microservice that implements a bounded context made of 3 aggregates and one transactional boundary per aggregate, and I've faced some pain points:

• Eventual consistency within the Microservice itself
• Atomic update of the aggregates and publication of domain events within the Microservice in a resilient way
• Deciding whether all the domain events shall be published externally (to other Microservices) or only some of them
• Deciding whether the domain events shall be published in the form of integration events in order to preserve the purity of the domain model

Then I've envisioned the possibility to split the Microservice into several Microservices, one per aggregate:

• It gets more natural to publish all domain events (no clear need to make a difference between domain events and integration events)
• The internal complexity of the Microservice is reduced

I've not managed to find some documentation on this subject to guide me in the decision making.

Edit:

Would it make sense to consider that the bounded context could be a set of Microservices working together as partners, and where each Microservice would encapsulate one and only one aggregate with its own scaling strategy?

Then, each Microservice would have one and only one reason to change: the aggregate.

Answer 1

Of course the answer is always "it depends". In this case though, most of the time, you would want a microservice to contain everything that is necessary for a closed set of functionalities. Note I said "functionalities", as in business functions. Not technical functions, like saving a "Person" to a table, but business ones, like 'transfer money from one account to the other', 'reserve seat', things like that.

In your terms it would mean to contain one transactional boundary, and probably multiple "aggregates".

All of this is because of maintainability. When you modify a given functionality (or fix a bug, etc.) you will want that to be localized to a single microservice. Anything that requires coordination between microservices is usually much more difficult. You have to coordinate teams, coordinate rollout, etc., and that is exactly what microservices are supposed to be a solution for.