Do microservices break a limited context?

Question

I'm a little confused. I work for a young banking company, and we decided to implement DDD architecture in order to destroy complexity.

So here is my question (this follows the design proposal made by someone on the team). Let them say that we have 3 different domains. D1, D2, D3, which provide domain (network) services. Each domain manipulates strongly typed business objects that rely on the same tables. In front of these domains, we want the microservice to ensure that the data stored in the tables is consistent, centrally. D1, D2, and D3 require the microservice to store data that conforms to certain rules. We want the microservice to act as a CRUD proxy for tables. The microservice provides specific DTOs for domains D1, D2 and D3, dipping tables D1, D2, D3.

Is this approach good? Could you use the microservices in the DDD architecture to control CRUD and data consistency for 1+ domains? Does CRUDING and microservice data verification violate a limited context? What are the best practices for working with microservices in the DDD architecture, if any?

Thanks so much for your input,

[EDIT]

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

Microservices are useful in difficult situations when monolithic systems cannot withstand maintenance. They are not good candidates for upfront design implementations. On the other hand, DDD is trying to solve complexity at the very beginning of projects. A successful DDD does not have to match microservice implementations.

Answer 1

Things like validation, computation, and persistence (CRUD) are all functions, not services. By centralizing these tasks for one service, you closely associate all other services with it and lose the main advantage of SOA. Direct linking of your services, while maintaining high cohesion, should be your main goal. I feel this design violates this.

You want to create your services as vertical slices of related business functions, rather than with centralized generic services and levels. The service should consist of components that are deployed throughout the enterprise from the database right through to the user interface. In addition, each service should have its own database, or at least a schema, if this is not practical. Once you have the services sharing the database, you become tightly connected again.

In conclusion, if one of your services needs a simple CRUD insert, then everything should be. No need to map it to the domain model first. Save DDD for business processes with real invariants that need to be performed. It should not be all or nothing. Use a tool that makes sense for each use case.

Answer 2

Microservices should not "break" limited contexts, they complement each other, since there is a natural correlation between microservices and BC boundaries .

we want the microservice to guarantee that data is stored in tables in a consistent, centralized manner

Microservices are not for facade purposes here. And they all relate to decentralization, not centralization. They are modular units organized according to business opportunities. They will usually act as gateways to your limited contexts in front of the Domain, rather than proxies in the persistent storage behind the Domain.

It seems that you are trying to apply the wrong solution to your problem - using microservices, because the points of convergence are tied to a data-oriented monolith , which damages their entire purpose.

Perhaps you should elaborate on what you mean by "guaranteed data of guaranteed compliance" and "save data that complies with certain rules." It can simply be implemented at the retention level or in services that are not microservices.