Does layered architecture still to be implemented inside all other architecture pattern like SOA and Microservices?

Question

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?

Answer 1

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.

Answer 2

Most of the domain driven design leaders prefer aligning microservices with bounded context (Eric Evans - DDD and Microservices: At Last, Some Boundaries! and Vaughn Vernon said using a Domain-driven design (DDD) approach, especially bounded contexts). If you follow the DDD leaders suggestion, you wouldn't get tiny services. That means it's also beneficial to carefully structure the code inside the service.

However, as Vaughn Vernon says in his IDDD book

These days many teams that say they are using a Layer Architecture are actually using Hexagonal instead.

With well accepted concept of Dependency Inversion Principle and good supporting Dependency Injection in different platforms, Hexagonal (also known as Ports & Adapters) is quite easy to implement.

In the example of ThumpImageService in the question, it looks quite simple. The question is will this service always such simple, will it, for example, involve to managing other resources, will you have different thump images per theme/profile. And another question is whether most of your services are such simple. The point is microservices or DDD are better to be used to "Tackling Complexity in the Heart of Software". I like the idea of "DDD Scorecard"(in IDDD book) very much. Before going to deep, we should score the project and evaluate whether the project worth such overhead.

Answer 3

You are talking apples and oranges here when you mix the ui, api, data or logic layers with Docker. Docker is an implementation concerns; architectural patterns are conceptual.

What the container model allows you to do is deploy individual layers of your application - if it was so built - into individual containers. Theoretically you could run ui, api, data or logic layers in clusters of Docker containers that are wired together synchronously or asynchronously. On the other hand, you could mash them all into a single container if your application has a very small footprint.

What you need to do is first and foremost analyse what you are doing and then how that breaks down into logical components. A lot depends on how big your project is, its requirements for scalability and reliability, as well as the realities of how long it will be around.

Patterns are just guidelines that must be evaluated in the context of your own needs. Small project for small user base? You may waste loads of time trying to have a conceptually elegant architecture, when the cost is not justified by the business case. Large project, multiple development teams, long product life ... then a pattern is essential, otherwise you'll be lost.

Architectural layers make sense not just for separating development and testing concerns, but for implementing more scalable systems. For example, as an API layer normally has to be extremely resilient and responsive, you may need a larger cluster of user-facing containers that can always respond to requests. On the other hand, you might have various business logic components which are lightly used, and so can run in single containers.

In other words: know what you are doing, figure out how it has to be deployed, then see what architectural layers make sense for creating a long-running and stable system.