Group Members:
- Mohemmed Mossa Abdul-riza
- Wisdan Anes
- Mustafa Buga
-
Instructions on how to build, start, and run the project. if you have more than one means of running the project (for example, docker containers run locally, docker containers running on dockerhub, or running the individual services locally), make sure you have clear instructions for each of these.
-
An overview of the project (you can use the one from the arbeidskrav as a basis). The overview should accurately describe the project implementation.
-
A list of user stories that allow an examiner to assess the functionality developed in the project (think of the most interesting and important scenarios that the examiner can run to see what functionality you have implemented).
-
A diagram showing the architecture of your system. This should show what services the project contains and what type of communication they have between them (synchronous or asynchronous).
-
if you collaborated with other students on a project, the README.md file should also contain a discussion of the contributions and responsibilities of each team member. During development, you may have to make a number of architecture decisions, assumptions about the domain you are working with, or simplifications to how such a project would work in reality. Document these decisions, assumptions, and simplifications in the README.md file.
-
Use multiple services, that fulfill different functionality and communicate with each other
-
At least two of the services communicate using synchronous communication (for example, direct REST calls between two services).
-
At least two of the services communicate using asynchronous communication (for example, using Message Queue). This will be done in accordance with event-driven architecture, as discussed in class.
Required (but not sufficient) for D
-
Each service has a clear structure and functionality.
-
The architecture of the project is consistent with the documentation. (All services are described in the architecture, they can be found in the project, their functionality, structure, interactions are documented.
-
The project can be deployed as a group of Docker containers.
Required (but not sufficient) for C
-
The project uses a unique access point, that handled calls and routes them to appropriate services – Gateway
-
The project uses a unique access point that, in addition to routing calls, also does load balancing
Required (but not sufficient) for B
-
The project has a means of centrally controlling the health of running services – health check
-
The project, and all services and necessary components, can be started via docker compose (using the command ‘docker compose up’). The project is ready for integration into a CI/CD pipeline.
Required (but not sufficient) for A
-
The project has a means of centrally controlling configurations for the services – for example, using Consul
-
The project can be deployed with multiple instances of relevant services of the services.