domain driven design - Do microservices break the bounded context? -

i bit confused. working in young banking company , decided implement ddd architecture break complexity.

so, here question (it follows design suggestion made in team). let's have 3 different domains. d1, d2, d3, expose domain (web)services. each domain manipulates typed business entities, rely on same tables. in front of these domains, want microservice garantee data persisted in tables consistent, in centralized manner. d1, d2 , d3 ask microservice persist data conforming specific rules. want microservice act crud proxy tables. microservice provides specific dtos d1, d2 , d3 domains, obfuscating tables d1, d2, d3.

does approach sound ? consider using microservices in ddd architecture manage crud , data consistency 1+ domains ? "cruding" , validating data microservice break bounded context ? best practices dealing microservices in ddd architecture, if ?

many contribution,

[edit]

the following article helped me refine thoughts : http://martinfowler.com/bliki/microservicepremium.html

microservices useful on complex situations monolithic systems failed @ being maintainable. not candidates upfront design implementations. on other hand, ddd tries tackle complexity @ beginning of projects. successful ddd should not meet microservices implementations.

things validation, calculation, , persistence (crud) functions , not services. centralizing these tasks 1 service tightly coupling other services it, , lose main benefit of soa. making services loosely coupled while retaining high cohesion should primary goal. feel design violates that.

you want design services vertical slices of related business functions, rather centralized generic services , layers. service should comprised of components deployed throughout enterprise database way ui. each service should have it's own database or @ least schema if that's not practical. have services sharing database, become tightly coupled again.

on final note, if 1 of services needs simple crud insert, that's should be. no need map domain model first. save ddd business processes have real invariants need enforced. doesn't have or nothing approach. use tool makes sense each use case.