7

I am having a long-term debate with my architect about architecture choices. The entreprise where I work in is migrating from a monolithic architecture to a microservices one.

The debate is located on the good approach for handling database access. One of us is standing there is no need for separating DAO and service (database access are directly handled by the service class), and the other stands for the contrary.

We are discussing about it for days, and I can't find good reason for convincing him, and he cannot either convince me.

The question is actually really simple: in an atomic REST microservice (a microservice handling only one REST method), should we have a separate DAO class or not? Which arguments could you give for separating, or keeping everything together?

This is a OOP oriented project (Java), if it matters.

Rémi Doolaeghe
  • 171
  • 3
  • Possibly your architect should be more concerned with architecture than code organisation concerns. – Mr Cochese Oct 28 '16 at 13:48
  • 1
    It depends, in a microservices structure every service encapsulates its own data. So in service one it may be useful and in a second it is not. There is no explicit need to make them all the same. As long as you comply with the external agreed api you are fine with both. The implementation is not something which has to be uniform. – Luc Franken Oct 28 '16 at 15:08
  • 1
    IMO it's not your job to convince someone who is supposed to be your reference. You already know the 'good reasons'. He probably too. If it make you feel better, let me say that **architects some times are wrong**. – Laiv Oct 28 '16 at 19:24
  • @Laiv You're right, we have to decide which choice best fits our situation. I'd like to precise I am not trying to be right, just to find the best answer for our situation. – Rémi Doolaeghe Oct 31 '16 at 07:53

2 Answers2

6

You don't have to argue about it for "days." In that amount of time, you can actually implement a microservice of the size you're describing both ways and compare for yourself. Look at how easy the code is to read. Look at how easy it is to write unit tests and integration tests. Honestly evaluate the code's coupling and cohesion.

I can save you some time, though. Our team occasionally inherits ownership of services that don't separate responsibilities properly, and they have always been fragile, error prone, and difficult to test. When we need to make our first change after we become owners, we have found it is faster and safer to plan to separate the layers before making the change.

Microservices provide nice external boundaries, but that doesn't mean you throw out normal design principles within the service.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
3

There is no reason that multiple micro services can't share a common core library that contains (drum roll, please) all the common data access classes! Then your micro service is free to pick and choose which DAO/repository classes it needs. Maybe you need multiple repositories or data access objects in one micro service.

The reason to separate them boils down to the Single Responsibility Principal: A class should only have one reason to change.

As soon as you start embedding data access logic in one application, you introduce the risk of that logic being copied and pasted into another application allowing code duplication to sneak in to your ecosystem. A micro service should be atomic in the function it serves. It doesn't have to be atomic in the code it contains.

From Martin Fowler:

...the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process...

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Notice that it mentions nothing about how you should design the data access components, and instead focuses on the function for which the service is built.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • 1
    If you have several services that are accessing the same data store to provide different functions, this may be true. If not, applying DRY rigorously can lead to information leakage, and in the end, tighter coupling that prevents services from evolving independently (as you are presumably moving to microservices to enable them to do). – ebullient Oct 29 '16 at 03:01