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.

Answer 1

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.

Answer 2

Microservices are not supposed to "break" Bounded Contexts, they are complementary since there's a natural correlation between microservice and BC boundaries.

we want a microservice to garantee that data persisted in tables is consistent, in a centralized manner

Microservices are not here for facading purposes. And they are all about decentralisation, not centralization. They are modular units organized around business capabilities. They will usually act as gateways to your Bounded Contexts, in front of the Domain, not proxies to a persistent store behind the Domain.

It seems you're trying to apply the wrong solution to your problem -- using microservices as convergence points to a data-centric monolith, which defeats their whole purpose.

Maybe you should elaborate on what you mean by "guarantee data persisted is consistent" and "persist data conforming to specific rules". It might just be implemented in the persistence layer or in services that are not microservices.