-
Notifications
You must be signed in to change notification settings - Fork 0
Record of architectural decisions
This decision was made at the beginning of the first team meeting. Without a doubt, this is the most important architectural decision, as it will mean not being able to modify the master branch without all members having previously reviewed the modifications, so that nothing is added that could affect the functioning of the main branch. In addition to this, a develop branch was also created, which will function as a main2.0 branch for adding progress as it is made. To add to this branch also requires the approval of some members of the team.
This is a decision we took on Tuesday 6 February, after the second session. So far this project is one of the most important decisions so far, as it will mean not using the base project and starting another application in another programming language. We have come to this decision because we consider it much more accessible to use the Java language, as it has been taught from the beginning of the course. Moreover, with what we learn in the subject SDI (Distributed Systems and Internet) we can apply it all to web development, using the Spring framework. We have also found a Java library with which we can use Wikidata very easily. It was a unanimous decision that will make it easier for us to work smoothly in the long run.
We have implemented the Model-View-Controller (MVC) pattern to implement user interfaces, handle data, and control logic. In this way we separate the concerns between business logic and visual presentation, which allows better organization of work and facilitates code maintenance.
We decided to employ a hexagonal architecture because of its focus on separation of responsibilities. In addition, it gives us greater flexibility by isolating the core of the application, protecting it from external dependencies. We chose it because it provides us with maintainability, scalability and adaptability.
We selected the Data Transfer Object (DTO) pattern due to the ease it gives us to separate the business logic. As it is a pattern that we already knew from other subjects, we were able to implement it in a simple way and take advantage of the separation of responsibilities and compatibility with external interfaces that it offers us.
We made the decision to use the MySql database for production and HSQLDB for local work. MySQL because we have a strong entity structure, and in production because it is faster. On the other hand, HSQLDB is easier to deploy locally, which saves us a lot of time for testing.
We decided to use the monolithic architecture because of the simplicity it offers us, with all the application components residing in a single code base, but without losing performance.
Using gitflow model allows us to merge small updates frequently, using short-lived branches to iterate quickly in the develop branch, and when the app has the features we want for a release, we merge it into main. We chose it because it contributed a lot to us for continuous delivery and collaboration
Every time the application is started, the questions are refreshed, and every 24h after startup. We decided to do it this way so that there is no continuous consumption of resources and requests to the wikidata service, thus improving performance. The refreshing also makes sure that questions are always up-to-date, meaning that new data that is fed into wikidata, world events, or other possible causes of data changes are accounted for.