New to the microservices architecture - but what I've picked up so far doing some research while designing a microservices architecture for a home rental system is these:

  1. Individual microservice should be as loosely coupled as possible - that doesn't mean they shouldn't communicate but not to the level that one microservice can edit business logic data of the other microservice (shared databases etc.)

  2. All communications should be restricted to information sharing via an event broker (pub-sub model) - for example a userId needs shared across multiple microservices, once the registration service has completed registering a user.

So considering the above key points, as design best practice for microservices, how does a bounded context help in scaling or a better design pattern? Does it help at all or is just a technical jargon ? even in a bounded context we still need the decoupling concept of a microservice to keep them as independently developed and maintained as possible, right ?

Some practical examples from expert experience would be a great help

  • There's a lot of confusion and misconceptions in the industry about what a bounded context is actually meant to represent (including there tutorials and documentation from fairly trustworthy sources - such as big software companies). The way most people are using the term, it's not entirely aligned to the original meaning as proposed by Eric Evans here. It would help the answerers if you expanded a bit on what you understood "bounded context" to be, based on your research. Dec 1, 2023 at 15:49

1 Answer 1


Bounded Contexts as a strategic pattern have several benefits:

  • They are linguistic boundaries. A concept may have a different meaning to different parts of the business. By acknowledging this and creating boundaries around those parts, we can create software tailored for the specific needs of that part of the business.
  • When we've identified Bounded Contexts, we can decide what type of sub-domain it belongs to (Core, Supporting or Generic) so that we can decide how much development effort is warranted for that BC.

So far, Bounded Contexts have no direct relation to microservices, they are equally valid for software deployed as a single unit.

We should choose a microservice architecture when we run into organizational issues that can occur when multiple development teams are working on the same code base. At some point, the overhead caused by merging code and communication between teams slows down the development. When this happens, you'll have to decide how to split the code base so that different teams do not interfere (as much) with each other. It turns out that the Bounded Context boundaries are often a good fit for this.

Finally, the term 'microservice' is not as well defined as you might think. A team working on software within a Bounded Context can work on different applications or services. Be careful though not to create Entity Services where a service basically represents an entity in a relation database. That, imo, is a recipe for disaster. As long as you don't need independently scalable services, start with a single service for all Aggregates you have identified within the Bounded Context.

  • I agree that microservices are mostly about organizational structure, not technical decisions. However, I do think that there is a connection to the "bounded context" concept: if the responsibility for dealing with a context is divided across multiple services, those services are likely to be very tightly coupled. In contrast, context boundaries are also good candidates for APIs and interfaces of services.
    – amon
    Dec 1, 2023 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.