Micro service architecture : Data Access services

user_5052685 0
Viewed 1100

In a micro service architecture, Is it good to have separate DAO services for all the Business services or should I have all the layers intact in the service. In my case, I am building a small Banking application where in I have below services 

cbs-accountsummary
cbs-payments
cbs-accounts
cbs-loan
cbs-deposits

So should I really require below services as well 

cbs-accountsummary-dao
cbs-payments-dao
cbs-accounts-dao
cbs-loan-dao
cbs-deposits-dao

Or is it fine to have DAO as part of business services. I am really wondering how it goes in real life applications.

microservices
2 Answers

As already said, I would not go for separate DAO-Services. A Microservice should control all aspects for the bounded context it is responsible for, this includes persistence.

Imagine, if there would be seperate DAO-Services, what would prevent a client from modifying, via said services, the data of the Microservice itself? The Microservice applies business logic onto its domain objects and persists them or not (in case of business rule violation). You never want this to be circumvented. See "cohesive behavior" of Sam Newmans book Building Microservices.

user_10874790

In micro-services architecture you split your Domain to micro-services and each micro-service will have its own: api, business logic and data access.

Your example

In your case for example the micro-service "cbs-payments" will have its own API exposed, as well as a business layer(the domain logic of the payments domain) and data access layer. The micro-service will be responsible for the whole scope of the request from api to data persistence. This could include api's, business logic, cache, database and other things.

Lets say if you have a Create payment api call. You would call your micro-service REST api like POST api/payments which would process the request, apply some business rules(validation and others) and save it to the micro-service specific database. All that code would be in your micro-service.

The confusion

Maybe your where working with systems where the the architectural split was not done based on the domain but on some other criteria. Usually micro-services are split based on some Domain boundaries like in your example. Each of these micro-services are isolated. Regardless of business logic, data access logic or any other logic it is still part of that micro-service. Usually people use DDD(Domain Driven Design) with micro-services. It is also a common approach to use Repository and Unit Of Work design patterns. You could create Generic Repository/Unit of Work classes which help in database interaction. If you are using micro-service architecture you can extract these generic implementation to some library and use them in each micro-service(extend them if needed). Still you would use that code in your micro-service code.

user_17756930
Related