Added the ADRs from last submission. These still need to be revised to reflect more recent design choices

.adr-dir

@@ -0,0 +1 @@
+doc/architecture/decisions

doc/architecture/decisions/0001-record-architecture-decisions.md

@@ -0,0 +1,19 @@
+# 1. Record architecture decisions
+
+Date: 2021-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools).

doc/architecture/decisions/0002-seperate-service-for-executors.md

@@ -0,0 +1,21 @@
+# 2. Seperate service for Executors
+
+Date: 2021-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+The users need to be able to add new executors to the executor pool. The functionality of the executor is currently unknown.
+
+## Decision
+
+We will use a separate microservice for each executor.
+New executors will be added/removed during runtime. Therefore, we need a high extensibility.
+Different executors can have different execution times and a different load. This means the executors scale differently.
+
+## Consequences
+
+Having executors as its own service we can deploy new executors independently and easily add new executors during runtime and guarantee high scalability as well as evolvability.

doc/architecture/decisions/0003-seperate-service-for-assignment-domain.md

@@ -0,0 +1,21 @@
+# 3. Seperate service for assignment domain
+
+Date: 2021-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+The Assignment Service handles the assignment of a task to a corresponding and available executor. It keeps track of all the connections between tasks and executors.
+
+## Decision
+
+The assignment domain will be its own service.
+The assignment service will be a central point in our application. It will have most of the business logic in it and will communicate with all the different services. Therefore, other services can be kind of “dumb” and only need to focus on their simple tasks.
+The code of the assignment will change more often than the code of the other services, thus having the assignment service split from the other makes it more deployable.
+
+## Consequences
+
+Having this system as its own service we reduce the Fault tolerance because the assignment service can be the single point of failure. We can mitigate this risk by implementing (server) replication and/or having an event driven communication with persisting messages. Therefore, all other services can run independently, and the assignment service can recover from a crash.

doc/architecture/decisions/0004-seperate-service-for-executor-pool.md

@@ -0,0 +1,21 @@
+# 4. Seperate service for executor pool
+
+Date: 2021-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+The Executor pool keeps track of the connected executors and their purpose and status.
+
+## Decision
+
+We will have a separate service for the executor pool.
+There are no other domains which share the same or similar functionality.
+The executor pool also scales differently than other services.
+
+## Consequences
+
+Having the executor pool as a separate service will help with the deployability of this service but will make the overall structure more complex and reduces testability.

doc/architecture/decisions/0005-event-driven-communication.md

@@ -0,0 +1,20 @@
+# 5. Event driven communication
+
+Date: 2021-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+Services need to be able to communicate with each other. Services need to be scalable and therefore multiple services will need to get the same messages. Most of the processes are about responding to events that are happening throughout the system.
+
+## Decision
+
+We will use mainly event driven communication.
+
+## Consequences
+
+Event driven communication will help use to create a system which has high scalability and elasticity. Through persisting messages, we will also reach way higher fault tolerance and recoverability.
+Having an event driven communication, we can only guarantee eventual consistency.

doc/architecture/decisions/0006-one-global-database-or-one-database-per-service.md

@@ -0,0 +1,20 @@
+# 6. One global database or one database per service
+
+Date: 2021-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+We can have one database for all services or each Microservice can have its own database.
+
+## Decision
+
+Each Microservice will have its own database.
+The different services don’t need to store a lot of similar data. Therefore, we can have every Microservice handle its own data. This also gives the advantage that every Microservice owns its own data and is also responsible for it. (Data ownership, Data responsibility).
+
+## Consequences
+
+Having one database per Microservice will lead to eventual consistency. Having an event driven communication we can use event-based synchronisation to keep the data in sync between the services, thus the individual services don’t need to know about each other. To guarantee data consistency we can also use a pattern like sagas.