When we design the whole system we have few architecture pattern to select from. One of them is the layered architecture pattern, This pattern seems to be generic enough to fit in all other architecture patterns but with different scale.
For example if we choose Microservice architecture, each service still need it is own layers. Service either in SOA or Microservice need a persistence, service and application layer.
Sometimes the service is too small like createThumpImageService, which will only take image and to create thump of it then store the new thump in blob storage. If Such service with 10 lines of code layered, I think it will be over engineered.
My question is when layered architecture fit in ( component , subsystem , service , microservice) and when not?
If there some cases that layered architecture not the best choice, what alternative solutions that give us the decoupling and abstraction of layered architecture?
Best Answer
It's all about semantics.
Enforcing layers will help to keep the code clean in responsibilities. (Single responsibility principle). Your mental stack will be minimized in each layer when separating concerns. And you gain flexibility in interchanging layers.
Using layers is the vertical way to organize code mass. And that is the same with organizing people. You have to spent more time in organizing them if you have more people.
One thing to microservices:
They do not adress layers, they adress the horizontal way (functional way) to organize code mass. Here again: More code, more separation. But be careful:
Microservices may give up consistency if they are missing the "bigger" context of your whole domain. So if I design microservices they are an outbound view of parts of my business domain model considering global consistency.
So most of the time I would not divide the business layer into smaller pieces as you may loose the possibility to check global constraints OR you will have to consider these consistency constraints in your microservice protocol, making them a lot more complex.
For me UI, Usecases, Business logic and DAO layers are essential and univeral in semantics. I don't think we have to discuss about the UI. Usecases will model the current work flow of a user. Business logic will check local and global constraints to ensure system-wide consistency, furthermore it orchestrates the DAOs. And the DAO layer will abstract from the type of data holders.
After all only one thing matters: The maximum profit of the business you are working for. So your expenses to separate concerns should be balanced with the income achieving with the application to the maximum profit.