7

In the past few days I've been reading some things about microservices architecture. I didn't get the whole point yet, since I'm just starting with this, but there's one point which caught my attention. In some sense it seems to me that microservices are a concrete way to leverage the idea of Bounded Contexts from DDD.

I mean, microservices as I understood, are full applications, loosely coupled, which are self-contained. Usually each microservice is developed by its own team, has its own codebase and are deployed independently. In the end they work together to form the full software being developed.

This really seems like bounded contexts. Of course, bounded contexts are more like a concept. Microservices seems to be one way of implementing that concept in practice.

Is that right? Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD? If not, why is that? I believe that if that's not the case, understanding why might improve both the understanding of bounded contexts and microservices.

5

I believe your question is a catgory error. In short, microservices are a way of organizing your architecture, while bounded contexts are a way of organizing the classes/objects you manipulate in code. There may be a one-to-one correlation between the two, or there may not be. There is certainly no necessary connection between the concepts.

If I may borrow Martin Fowler's example of bounded contexts:

enter image description here

In this case, bounded contexts simply tells us that we need a different Product class in the sales context than we do in the support context. That doesn't tell us where or how these classes should be stored or retrieved. For example:

  • This can be implemented without microservices at all. If this is a simple rich client application that never talks to the internet, obviously microservices won't make a lot of sense.

  • You can implement this with one microservice per context. Perhaps the sales and support contexts are each represented by a single database, and each database has a single microservice. Then you would talk to the sales microservice to get your SalesProduct, and the support microservice to get your SupportProduct.

  • Alternatively, you can implement this with one microservice per object type. There may be a product database that stores both the sales and support info, and you can ask the microservice for one or the other version of the Product. Or maybe you only ask it for a blob of info, and using that blob to instantiate a SupportProduct versus a SalesProduct is done somewhere else.

2

Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD?

They way you are asking the question you are implying a strong relationship between microservices and bounded contexts. I thing that is a misunderstanding (but maybe that's not really what you meant, just how the words came out).

I would rather say that microservices could be a good fit for implementing your bounded context if you are implementing DDD.

Remember, not every project uses DDD (and most that do, properly doesn't do it properly anyway). In these cases microservices can be applicable.

0

Bounded Contexts and Microservices are similar but (from my understanding) a Bounded Context can consist of several Microservices. From Martin Fowler's description of the Bounded Context, each rectangle in the bounded contexts of his illustration could be one Microservice, so you'd conceivably have one for Tickets, one for defects, etc. Or several of these services could be combined into a larger Microservice, all the way up to one Microservice for the entire Bounded Context.

0

Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD?

I agree with that, though I'd pose it a different way, more like Pete did.

Bounded context is just an arbitrary area with some tangible boundary, or fence. When they are implemented with microservices, this boundary coincides with process boundary (which is, just in case, a poor indicator of (micro-)service boundary). You can come up with your own boundary type. For example, it can be a higher-level project directory, something that is more high-level than modules. Anyway, this is just one, "run-time" perspective to look at the concept of Bounded context.

Say, your domain expert doesn't know what a microservice is. Bounded context for him or her is just some visual representation on a whiteboard, where specific terms make sense, certain functionality resides and its own ubiquitous language applies.

Finally, understanding how to decompose your domain and define bounded contexts is a critical step that you don't want to mess up with, since it strongly affects the whole lifetime of a system.

0

There are differing opinions on how bounded contexts should relate to microservices, some of these opinions are largely predicated on how a microservice is defined.

Those who say there shouldn't be a one to one correspondence are generally conceiving of a microservice as physical service, a process like a ASP.NET application. They argue that many services can share the bounded context. If the definition of a microservice is a physical service then I would agree with them.

However, I prefer to think of a microservice as an API, which might be be physically implemented as multiple processes. On these terms a microservice can consist of multiple processes (web services, chron jobs, etc), indeed if you are using CQRS and reads are separated from writes at the process level, you almost have to adhere to this multi-process definition of a microservice. And if we adhere to this definition, I think it is best that a multi-process microservice to correspond to an individual bounded context. It helps with cognitive scope, with team organization and division of responsibility.

Your Answer

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

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