Understanding the interactions between your systems will allow you to make better, more accurate decisions in the long term.
Poor service abstraction: Snowball effects: Inflexible legacy systems: Data access layer
Other models have fewer or more levels, but any model you work with will always have a way for users to interact with the application, a way to deliver data, a central processing system that handles the calculations, and a place where the data are stored. .
Presentation layer
This layer deals with the user interface, it is the part of the application that handles user input, manages user requests, sends requests to data services, presents outputs and basically handles all other forms of user-application interaction. For example, in the case of web applications, this is what we call a frontend, using technologies such as JavaScript, HTML and CSS to create the part of your website that is consumed by the customer.
Data Service Layer
This layer acts as a bridge between the presentation layer and the business logic layer. From a security perspective, it's a wall that separates what the user is doing from the core logic of your application, making it safer for you and your customers.
Business logic layer
The brains of the operation , this layer is where data is exchanged or processed, encoding user inputs and/or preparing information to be relayed to the presentation layer. For example, in a dynamic web application, this is the part of the application that decides what information is required by the presentation layer. It takes the information from the data store, makes the necessary preparations, and sends it to be displayed by the user.
Data Access Layer
This is where data is stored, most often using SQL or NoSQL solutions. It is the layer from which data is accessed and sent.
What are the different types of application architectures?
While there are too many to summarize in a single article, you should at least be aware that there are dozens of architectures. Some are much more popular than others, and that's what we'll talk about today.
Monolithic Architectures
Also known as 3-Tier Application Model . Although most people consider it outdated by modern standards, it is still used, especially on legacy systems. In this model, the architecture is a single monolithic entity managed by a single team. The application becomes a huge system of intertwined instructions that becomes more unwieldy as it grows.
Microservices architecture
With this architectural style, applications are structured as a collection of independent services . Each may use different technology, such as being written in different programming languages, and may be tested separately from the rest of the system. Each service is related to a core business function and can be deployed separately from the others.
Event-driven serverless architecture
This type of architecture works as a series of decoupled systems that run in response to events. In this case, we do not have servers, but rather services waiting for something to happen and acting in response. This is a very lean and fast architecture that can be easily scaled and cost-effective, as you only use what is needed when it is needed.
Cloud architecture
This architecture is similar to microservices and event-driven architecture, but with the added caveat that it is designed specifically to take full advantage of cloud technology . For example, architecture that can automatically scale based on requirements or combine different services from one or more cloud providers.
Never is too late…
So what if you already have an application without a clear architecture? It's too late? Of course not, having to create a diagram from an existing application is actually more common than anyone would like to admit. The sooner you start, the better, because as we've mentioned before, the longer you wait, the deeper you sink into the spaghetti hole.
