DAO as Service vs DAO as Library

Question

I have 3 different services which needs to access same database. Each of these service will serve different purpose and different queries. I can generalize them in following way

1. Service 1 -> Customer Inquires
2. Service 2 -> Order Processor (e.g.workflow for placed orders)
3. Service 3 -> Reporting

I have written a DAO to expose data. I am evaluating two system designs for scalability and maintenance.

Option 1: Write one more service to expose DAO functionality as Data Service.

Pros:

1. Load on database will be controlled and easy to scale-in/out as needed
2. Easy to maintain for future updates
3. Access control for various actions
4. clients doesn't have full access on underlying database

Cons:

1. Single point of failure
2. management of extra service
3. Need to enforce backward compatibility rules
4. In case of DataService downtime every service is affected (factors other than database downtime)

And

Option 2: Create a storage library out of DAO and use these library in above mentioned three services.

Pros:

1. distributed, impact radius is very small

Cons:

1. Every service get full access on database
2. Needs to update all three services for new features

• Which option is good and why?
• Any other ideas/architecture designs to consider?
• What are the things I need to consider when choosing architecture?

Answer 1

This is an opinion... We use option 1 when shared access to a database is needed. The encapsulation gives us the ability to support backwards-compatible service calls, which gives us far more reuse of our services. The management overhead is higher, but if you get a non-trivial number of client services, well worth the ability to control access.

Think if you have 10-20 services that are in use in dozens of apps. If you need to refactor the database (which will happen), the cost of getting all those apps updated, and synchronizing their deployment is monumental. Additionally, as you said, things like caching can be done centrally and scaled easily in a centralized service. Distributed cache invalidation is one of those tricky problems that ends up costing far more than avoiding the issue in the first place by centralizing access.

This is my experience only. YMMV. If your database schema is very static, you might not get as much benefit, or if you don't expect many scaling issues. Like I said, it's an opinion.

Answer 2

First of all, I would build separate DAO for each service as they all have different bounded contexts, from your description. For example, most likely, "Service 3 -> Reporting" will be a read only service used for pulling aggregated data and it should not be aware of Order Processor and Customer Inquires stuff. Also, consider having a separate db for reporting queries if you expect a lot of data as it might be too much load for one database and it will be easier to scale it.
Regarding your question about a service to expose the data, with separate DAO for each service I think it's better to put DAOs in a lib. This way each service will have access to the data it needs only and you won't have to deploy all services if you need to make a change to only one DAO. Also, you might want to have a base DAO to encapsulate common logic which is rarely changed. And keep in mind that having a service to expose data will add one more tier for the data to pass till it reaches the database unless you deploy the service to the same machine as the database. It might be crucial for high performance applications.

Answer 3

Thank you Rob and Maksym for your inputs.

I separated queries based on bounded context and created library and service for different context.

Service

Inquiry and Order Service access data using data service. This helped me control noisy neighbor and resource allocation.

Library

I replicated data from main database to reporting database and built a library for Reporting service to access reporting database.