Now that we’ve discussed layers and seen them as big horizontal slices of responsibilities, we can organize our applications more granularly by splitting those big slices vertically, creating multiple smaller layers. This can help us organize applications by features or by bounding context, and it could also allow us to compose various user interfaces using the same building blocks, which would be easier than reusing colossal-size layers.Here is a conceptual representation of this idea:
Figure 14.3: Organizing multiple applications using smaller partially shared layers
We can split an application into multiple features (vertically) and divide each into layers (horizontally). Based on the previous diagram, we named those features as follows:
- Inventory management
- Online shopping
- Others
So, we can bring in the online shopping domain and data layers to our Shopping web API without bringing everything else with it. Moreover, we can bring the online shopping domain layer to the mobile app and swap its data layer for another that talks to the web API.We could also use our web API as a plain and simple data access application with different logic attached to it while keeping the shopping data layer underneath.We could end up with the following recomposed applications (this is just one possible outcome):
Figure 14.4: Organizing multiple applications using smaller partially shared layers
These are just examples of what we can conceptually do with layers. However, the most important thing to remember is not how the diagrams are laid out but the specifications of the applications you are building. Only those specs and good analyses can help you create the best possible design for that exact problem. I used a hypothetical shopping example here, but it could have been anything.Splitting huge horizontal slices vertically makes each piece easier to reuse and share. This improvement can yield interesting results, especially if you have multiple frontend apps or plan to migrate away from a monolith.
A monolithic application (or monolith) is a program deployed as a single integrated piece with low modularity. A monolith can leverage layers or not. People often compare monolithic applications to microservices applications because they are antipodes. We explore microservices in Chapter 19, Introduction to Microservices Architecture, and monoliths in Chapter 20, Modular Monoliths.
Layers versus tiers versus assemblies
So far in this chapter, we have been talking about layers without talking about making them into code. Before jumping into that subject, I’d like to discuss tiers. You may have seen the term 3-tier architecture somewhere before or heard people talking about tiers and layers, possibly interchanging them in the same context as synonyms. However, they are not the same.In a nutshell:
- Tiers are physical
- Layers are logical
What is a Tier?
We can deploy each tier on its own machine. For example, you could have a database server, a server hosting your web API that contains the business logic (the domain), and another server that serves an Angular application (presentation); these are three tiers (three distinct machines), and each tier can scale independently.We look at layers next.
