#1 Update 08_concepts.adoc

docs/src/08_concepts.adoc

@@ -2,72 +2,87 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-concepts]]
 == Cross-cutting Concepts
+=== Domain model
 
+[options="header",cols="1,2"]
+|===
+|Name|Description
+| Player/User | User who can register, login and play in te application.
+| Question | Questions that are part of the game
+| Answer | Answers to these questions
+| Category | Game categories for the different questions
+| Wikidata | Wikidata model for data extracted from Wikidata
+|===
 
-[role="arc42help"]
-****
-.Content
-This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system.
-Such concepts are often related to multiple building blocks.
-They can include many different topics, such as
+image:08_domain_model.png["Domain Model - UML Diagram"]
 
-* models, especially domain models
-* architecture or design patterns
-* rules for using specific technology
-* principal, often technical decisions of an overarching (= cross-cutting) nature
-* implementation rules
+=== Persistence
 
+The database that best suited this application was a relational database, although non-relational databases are gaining more and more strength, it is too much for what is needed. In addition to this, the JPA adapter is made for relational databases, although any database can be adapted to the domain, MySQL was chosen for its simplicity and adaptability.
 
-.Motivation
-Concepts form the basis for _conceptual integrity_ (consistency, homogeneity) of the architecture. 
-Thus, they are an important contribution to achieve inner qualities of your system.
+=== User interface
 
-Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety. 
+The user interface is designed to offer all users an intuitive and familiar experience using the React framework combined with TypeScript. The website follows the usual standards for question-related websites, such as kahoot to make it more institutional and to have a model to build on. In terms of dependencies, we work with MUI for the components and Sass to give the application a defined style.
 
+Screens at a high level:
 
-.Form
-The form can be varied:
+image:08_screen_login.png["Login"]
 
-* concept papers with any kind of structure
-* cross-cutting model excerpts or scenarios using notations of the architecture views
-* sample implementations, especially for technical concepts
-* reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping)
+image:08_screen_home.png["Home"]
 
-.Structure
-A potential (but not mandatory) structure for this section could be:
+image08_screen_game_1.png["Game 1"]
 
-* Domain concepts
-* User Experience concepts (UX)
-* Safety and security concepts
-* Architecture and design patterns
-* "Under-the-hood"
-* development concepts
-* operational concepts
+image:08_screen_game_2.png["Game 2"]
 
-Note: it might be difficult to assign individual concepts to one specific topic
-on this list.
+image:08_screen_game_3.png["Game 3"]
 
-image::08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"]
+image:08_screen_historic.png["Historic"]
 
+image:08_screen_ranking.png["Ranking"]
 
-.Further Information
+=== Internazionalization
 
-See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
-****
+The application will potentially deal with several people, so making it a multilingual application seems the best decision. 
+This will allow us to reach a wider audience and make the application more accessible.
 
+The languages chosen are:
+[enumerate]
+. Spain
+. English
+. Germany
+. France
 
-=== _<Concept 1>_
 
-_<explanation>_
+=== Security
 
+For security and authentication we have made use of the keycloak library, which by means of roles, scopes and various configurations can take care of automating this security.
 
+=== Archiutecture and design patterns
 
-=== _<Concept 2>_
+==== Hexagonal architecture
 
-_<explanation>_
+the API is using hexagonal architecture in our app. We took this decision because it presents several advantadges.
 
-...
+The hexagonal architecture is an architectural pattern used in software design. It divides a system into different layers or regions with their own responsibility. In this way, it manages to decouple layers of our application, allowing them to evolve in isolation. In addition, having the system separated by responsibilities will facilitate reuse. The components are loosely-coupled and interchangeable, such as the application core, the database, the user interface, test scripts and interfaces with other systems.
 
-=== _<Concept n>_
+Hexagonal architecture is an alternative to traditional layered architecture.
 
-_<explanation>_
+image:08_hexagonal_arch.png["Hexagonal"]
+
+=== Testability
+
+Applications should be strongly tested. We use user stories to make acceptance tests and unit test to test the rest of the application components and states during running process.
+We think this is the best way to be sure the project works correctly.
+
+==== Postman
+To test API code, Postman was used during the whole development of the work, to check if the requests were being carried out correctly. Postman is an application in which we can test requests and obtain a successfully respond or not.
+
+==== Unit tests
+Unit testing was carried out on both the backend and frontend using different technologies to test all the necessary components or modules.
+The use of Mock for the backend and the use of jest for the frontend.
+
+==== Integration tests
+The integration tests were carried out in test containers with a test database built in these test containers for the adapter layer. It does not make sense to do integration tests on another layer.
+
+==== e2e tests
+For the e2e tests as well as the unit tests and in order to test the application to the maximum, they were carried out both in the frontend with cypress and in the backend with test container again.