Layered Architecture

The cake architecture! I don't think anyone calls it that but when you offer visual cues to represent this, it looks like a cake. I believe this is the most popular style in general, it's a straightforward and intuitive way to organize your system. This reminds me of the MVC model with a clean separation of concerns but expanded to a system-wide architecture choice. There are 4 layers that are commonly used: presentation, business, persistence, and database.

The presentation layer serves as the point of contact with the user. That's where the interaction with your application is defined. Today this is most likely a UI with any of the 1 million frameworks the ecosystem provides. In this layer the complexity of your system is hidden. There's a fine balance to find on where the complexity should lie. Should it be completely hidden from the user or should the user have some of the burden? I find that most of the complexity should be hidden from the user at first, but always leave room for advanced usage.

The business layer is where most of the distinguishing logic of your system lives. It generally receives the input from the presentation layer, applies business logic to it and eventually returns the result to the user. This might also involve reaching to the persistence layer. This is where the core of your application resides, we will mention this later but I think this is the least "replaceable" layer of all.

The persistence layer is the middle man between application logic and database layer. It abstracts away the interaction with the DB. If you are able to design this well it'll allow you to replace the DB without the rest of the application even knowing, as long as the same contract (interface) is satisfied

The database layer is where the actual storage of data happens. How about MongoDB? ;)

There are some benefits to organizing your system this way:

• The team can be organized in such a way that folks who are more versed in UI can make maximum use of their expertise. I have a hard time believing this is overall beneficial at a larger scale, also because the layered architecture doesn't lend itself to scaling that much. I have worked at smaller companies where this was, reasonably, the go-to architecture to bootstrap a product. I was already a promoter of having people be able to own development horizontally compared to the layers. This means nobody would be isolated to one layer and could independently introduce changes across layers. Realistically it was a slow process to communicate back and forth with people responsible for the development of layers below/above yours. On the other hand being able to have some ownership across layers was powerful and helped with velocity. People who had expertise were still there to support and guide the team while letting everyone be autonomous. At scale though this would not be sustainable.
• If done right. it's a good way to get started for most applications. I know it's a big "if" but it only takes a limited amount of discipline and some good leadership to drive this. Awareness of this being a starting point should be a good motivator to make a move to another architecture simpler.
• It's simple and familiar. Most engineers will encounter this at some point in their career. It can be a comfortable place to get started for anyone without strict requirements for high expertise in many different architecture styles.

Thoughts

While this is an appetizing approach, it comes at a price. Small changes can be riskier since they can affect multiple layers, additionally you would have to re-deploy an entire monolith for even the smallest change. I think this is partially true and depends heavily on the CD pipeline you have in place. I have seen this being a non-issue in my career. The limit of this though is the lack of independent scalability, you can't scale out an individual layer but you have to replicate the whole system to sustain, for example, a higher load. Given that these layers are coupled together, an issue with any of them will take the whole system down instead of being isolated. I think this can be mitigated with a good CD as I had a monolith that could deploy/restart within a few minutes. If you're starting out (which is where this style is recommended) your experience might be quite different. I think it's one of those things that, if done right, can get you somewhat far. Unfortunately it can turn into a giant mess or fall into the sinkhole anti-pattern quickly. If you have a disciplined team or some good technical leaders, it can be a good choice to move quickly and at a limited cost.