Understanding software architecture

#django #python #webdev #architecture

This is my first post in this platform, so this is kind of a beta test. At the same time, I want to record my studies in programming, specially the part that doesn't envolve coding.

One of my first difficulties in understanding web development was to figure it out how to plan and organize my scripts. From there, I started to search for the MVC method or for the case of django MVT. I stepped upon the method described by Clean Architecture, which cleared things a little bit and that's what I want to explain in this post.

What is Clean architecture?

"Clean architecture is a software design philosophy that separates the elements of a design into ring levels. An important goal of clean architecture is to provide developers with a way to organize code in such a way that it encapsulates the business logic but keeps it separate from the delivery mechanism."

The main rule of clean architecture is that code dependencies can only move from the outer levels inward. Code on the inner layers can have no knowledge of functions on the outer layers. The variables, functions and classes (any entities) that exist in the outer layers can not be mentioned in the more inward levels. It is recommended that data formats also stay separate between levels.

So, we must investigate what are those layers which the dependency occurs.

The order, so we can understand a little better, goes like this, from outside to the inside of the circle of clean architecture:

Frameworks & Drivers -> interface adapters -> application business Rules -> enterprise business rules

Let's start by understanding the enterprise business rules:

Entities and Classes - first and second layers

Entities are common classes for multiple systems in a project. Let's take a system of an university courses. We must assume that this university will deal with an academic environment (students, teachers, employees), financial organization, extensions with the community outside the university, etc... All of theses systems will deal with each other somehow, for example, students will deal with the financial side of the university and so on. Besides the credentials of each user of this system, there will be a logic applied to it. Teachers must be in a department, for example, as for students must be enrolled in courses.

In the cases of business logic, we will call it layer's classes. For example, in our system, we could have a diary concerning the courses offered by the university. We could have a class called StudentsDiary that storage objects concerning the students enrolled in a determined course which is being offered in a semester. A business rule can be defined in a way that the student can only be enrolled in a determined class if it has already done the necessaries courses as requesites for this desired course.

Adapters - third layer

In the third layer, from inside to the oustide, we have classes and interfaces named Adapters. Their function is to convert data from a type or format to another one.

Let's supose, for example, a system that uses a REST API for comunication with its clients. The adapaters classes will be, then, responsable for implamenting the REST endpoints of the API. It means that the classes will receive the requests and send them to their correspondent use.

These classes must the other way around as well: they will receive the results returned by the use cases and convert the in JSON documents that will be sent to the clients.

If the system is implemented by a MVC framework, all of the components of this architectural pattern - the view, the controller and the model - will belong to this layer.
(in the case of Django, it will be the model, the view and the template)

External Frameworks

In the most outside layer of all, the fourth layer, we have the classes from outside libraries and external frameworks, which can be responsable for the storage (or persistence) of the database. In this case it will be responsable as well for the construction of the interface with the users, sending emails, integrating a system with each other, the comunication with a certain hardware, etc...

For example, the university that we were thinking about can have a system for managing extension courses, it can accept payments with credit cards. For this, the system must use third parties services (the bank), which offers some classes for the payment processes. Thus, theses classes must stay in the outside layer of a Clean Architecture.

All theses details must stay in the layer of frameworks and drivers. The interaction with the web is just a detail for the whole architecture. The database, as well, is just a detail. We keep these technologies in the most oustide layer because it's where its configurations can be the less harm possible for the architecture.

Conclusion

So, from what we have seen, this whole organization can help us conceive a way of controlling our project in a hierarchical fashion, in which if one of the layers don't function as we plan, it won't trouble the other layers.

We can conclude that the best way to understand and figure out a web development project is in a way which the project won't make strange and confused knots between its parts.

The reason for this must be clear. Normally we don't work in a web project alone, even if we did, it's unconceivable to remember all of the project parts in a way in which is not organized. Since we are not alone in projects, we must envision our projects in a way that's fully understandable for every developer that dive into the projects.