Software architecture can be defined as an organization of the whole system. Like house architecture defines how many rooms in the house and how the air circulation works, software architecture also describes what components are used and how they interact with each other. Software Architecture will be used within the development and give the developer some advantages, such as clear work guidelines and systematic work. Like creating a house design, software architecture is also influenced by the environment in which the system will operate and the design principles used.
Monolithic or Microservices
The first thing to define about architecture is if our program will use monolithic or microservices in the development. To determine that, let’s look at our development goals and our work environment.
- There will < 10 admin only to use our working software.
- This application only saves journal metadata, so we don’t need an extensive capacity database.
- Every year the monitored journals are less than 100, so the load server won’t be that huge.
- This software was build from a MVP that has been used for years, and there’s no massive changes to it.
- Seven programmers ran this development in our team.
Considering the small number of human resources and not-so-fast evolving applications, but to build cleaner development we use microservice only for front end and backend.
In this development, we use Django in the backend, React for the front end, and PostgreSQL for the database. In defining working frameworks for the software architecture, we have to consider both the software and the working environments. Here’s how we define our working software :
- Familiarity. Familiarity is one of the main concerns when determining the working framework. The development phase in our project is pretty fast and neat. Learning a new framework will be exhausting and might hold up the development itself. We choose Django and PostgreSQL because all of us have done a project with those frameworks. And though not all of us familiar with react in the previous development, react learning material is everywhere on the internet!
- Third-party app request from the client: Thankfully, our client doesn’t have any framework preferences, so we can determine the framework ourselves.
- System Requirements. The system requirements of our software are flexible and do not forces us to use a specific framework.
We use a layered architecture to avoid pile-up implementation in a single file in this development. Using a layered architecture, we can be more focused on working on a specific layer. This leads to cleaner code implementation and low coupling.
Sometimes, we do not realize that we have defined some of it before in development. But, determining the whole software architecture helps to improve the development process.