Do microservices break the bounded context?

Question

I am a bit confused. I am working in a young banking company and we decided to implement a DDD architecture to break complexity.

So, here is my question (it follows a design suggestion made by someone in the team). Let's say we have 3 different domains. D1, D2, D3, that expose domain (web)services. Each domain manipulates strongly typed business entities, that rely on the same tables. In front of these domains, we want a microservice to garantee that data persisted in tables is consistent, in a centralized manner. D1, D2 and D3 ask the microservice to persist data conforming to specific rules. We want the microservice to act as a CRUD proxy to the tables. The microservice provides specific DTOs to D1, D2 and D3 domains, obfuscating the tables to D1, D2, D3.

Does this approach sound good ? Would you consider using microservices in a DDD architecture to manage CRUD and data consistency for 1+ domains ? Does "CRUDing" and validating data with a microservice break the bounded context ? What are the best practices with dealing with microservices in a DDD architecture, if any ?

Many thanks for your contribution,

[EDIT]

The following article helped me to refine my thoughts : http://martinfowler.com/bliki/MicroservicePremium.html

Microservices are useful on complex situations where monolithic systems failed at being maintainable. They are not good candidates for upfront design implementations. On the other hand, DDD tries to tackle complexity at the very beginning of the projects. Successful DDD should not meet microservices implementations.

Not sure this answers all your questions, but I found this to be an interesting read on the subject of microservices: particular.net/blog/microservices-future-or-empty-hype — Tyler Day
You can choose whatever architecture you want, there's no such thing as a DDD architecture. An architecture made up of microservices will work just as well (or not well) using DDD. — Adrian Thompson Phillips
In DDD multiple domains would not share the same database tables. This is also true for microservices. From what you've written in your question it sounds as though your system would not fit a DDD approach at all. — Adrian Thompson Phillips

Tyler Day Tyler Day · Accepted Answer · 2015-04-15T02:53:31

Things like validation, calculation, and persistence (CRUD) are all functions and not services. By centralizing these tasks to one service you are tightly coupling all the other services to it, and lose the main benefit of SOA. Making your services loosely coupled while retaining high cohesion should be your primary goal. I feel this design violates that.

You want to design your services as vertical slices of related business functions, rather than with centralized generic services and layers. A service should be comprised of components that are deployed throughout your enterprise from the database all the way to the UI. Also each service should have it's own database or at least schema if that's not practical. As soon as you have services sharing a database, then you become tightly coupled again.

On a final note, if one of your services needs to do a simple CRUD insert, then that's all it should be. No need to map it to a domain model first. Save DDD for the business processes that have real invariants that need to be enforced. It doesn't have to be an all or nothing approach. Use the tool that makes sense for each use case.

Do microservices break the bounded context?

2 Answers