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

@@ -0,0 +1,21 @@
+# 2. Seperate service for Executor Pool
+
+Date: 2021-11-21
+
+## Status
+
+Accepted
+
+## Context
+
+The Executor Pool has to keep track of which Executors are online and what task types they can execute. The Roster keeps track of tasks that need to be executed and assigns Executors to tasks. The Executor Pool functionalty could be implemented in a seperate service or as a part of the Roster.
+
+## Decision
+
+The executor pool will be implemented as a seperate service. (TODO decision might change. Need to reevaluate)
+
+TODO explain why.
+
+## Consequences
+
+TODO

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

@@ -1,23 +0,0 @@
-# 2. Seperate service for Executors and Executor Pool
-
-Date: 2021-11-21
-
-## Status
-
-Accepted
-
-## Context
-
-The executor pool has a complete list of all executors and knows if they are available or not, executors can execute tasks that match their type. The executors can therefore be part of the executor pool service, or each executor is a standalone service, as well as the executor pool.
-
-## Decision
-
-We will use a separate microservice for each executor and one service for the executor pool.
-Having the executor pool and the executors as separate services would increase fault tolerance. If the executor pool goes down, the executors would stay online and execute their tasks without being affected by the executor pool’s outage. Likewise, if an executor goes down it does not impact other executors or the executor pool.
-Different executors can have different execution times and a different load. This means the executors scale differently. Thus, we need a separate service for each executor.
-Executors of different kinds will also scale differently than the executor pool and new executors of new types might be added at some point, further increasing the need for separate services to guarantee scalability and evolvability.
-New executors will be added/removed during runtime. Therefore, we need a high extensibility.
-
-## Consequences
-
-Executors will be added/removed quite frequently, making the deployment of the system easier and less risk-prone if each executor is a separate service, also separated from the executor pool, which just keeps track of the executors and their status. However, having these separate services, the complexity might increase, and the testability of the system will decrease.

doc/architecture/decisions/0012-seperate-service-for-each-executor.md

@@ -0,0 +1,27 @@
+# 12. seperate service for each executor
+
+Date: 2021-11-21
+
+## Status
+
+Accepted
+
+## Context
+
+Executors must receive tasks of different types and execute them. The executors could either all be implemented within one service or as multiple services, one for each type of executor.
+
+## Decision
+
+We will have a seperate service for each type of executor.
+
+Firstly, execution time differs significantly between task types. Therefore, having seperate services will allow the executos to scale differently based on their tasks' specific needs.
+
+Secondly, the systems functioning should not be disrupted in case an Executor fails. Having each type of executor in a seperate service will increase fault tolerance in this regard.
+
+Lastly, extensibilty is one of the systems most important non-functional requirement and providers of executors need to be able to easily add executors to the executor pool. These factors are also positively impacted by having seperate services. 
+
+There should not be any shared data between the executors. Additionally, there should be no flow of information between them. Thus, there should be no issues due to workflow and data concerns due to this decision.
+
+## Consequences
+
+Executors share a lot of functionality when it comes to connecting to the rest of the system. Therefore, this decision means that we will either have to duplicate the code that implements the common functionality, or we have to have a way to share the code (e.g. through a common library)

doc/architecture/decisions/0013-microservice-architecture.md

@@ -0,0 +1,23 @@
+# 13. microservice architecture
+
+Date: 2021-12-02
+
+## Status
+
+Accepted
+
+## Context
+
+The system is made up of five distinct bounded contexts, namely the Task Domain, the Roster Domain, the Executor Pool Domain, the Executor Domain, and the Auction Domain. The way that these bounded contexts function together to fulfil the system requirements can be based on many different architectures. (Feedback needed. Should we name specific 'next-best' alternative architectures to compare, or just leave it as is since technically all architectures were considered)
+
+## Decision
+
+The system will follow the Microservice architecture. 
+
+Scalability and fault tolerance are two of the systems top 3 -ilities. Moreover, elasticity and evolvability are two of the systems other main -ilities. These are all non-functional requirements that the Microservice architecture excels at.
+
+We do not expect to have a single monolithic database, so this is not a concern.
+
+## Consequences
+
+There is a considerable amount of communication between bounded contexts. This could cause responsiveness and performance issues due to added latency. This could therefore mean we would need to use asynchronous REST calls or publish-subscribe communication to mitigate these issues as much of the communication does not have to be synchronous. 

doc/architecture/decisions/0014-data-ownership.md

@@ -0,0 +1,19 @@
+# 14. data ownership
+
+Date: 2021-12-02
+
+## Status
+
+Accepted
+
+## Context
+
+The issue motivating this decision, and any context that influences or constrains the decision.
+
+## Decision
+
+The change that we're proposing or have agreed to implement.
+
+## Consequences
+
+What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.