doc/architecture/decisions/0009-common-library-for-shared-code.md

@@ -0,0 +1,19 @@
+# 9. common library for shared code
+
+Date: 2021-11-21
+
+## Status
+
+Accepted
+
+## Context
+
+The numerous services that make up the Tapas app all have common, non-domain specific, functionality that can be shared via a common library, or be replicated in each service. 
+
+## Decision
+
+Use a common code library for shared code which does not change frequently, but if it would be changed, would need to be changed everywhere. 
+
+## Consequences
+
+Changes in the common code will most likely require multiple services to be redeployed. However, those services would most likely have to have been changed individually and redepolyed anyways. Another consequence is that versioning becomes more complicated. 

doc/architecture/decisions/0010-executor-base-library.md

@@ -0,0 +1,20 @@
+# 10. executor base library
+
+Date: 2021-11-21
+
+## Status
+
+Accepted
+
+## Context
+
+Executors all use the same logic to communicate with other services. This means that their code base is near identical except for the code that implements their specific task execution. The code that implements the executor's shared logic can either be implemented by a shared library, or replicated across all executors.
+
+## Decision
+
+Since all executors use the same logic to communicate with other services, any change to this logic would have to be made for every executor. We will therefore use a shared library for executors, called executor-base. The library includes all the shared logic which every executor needs. 
+Having this shared logic in a separate library makes it easy to change the common logic at one place. The code sharing happens at compile time, which reduces the chance of runtime errors, compared to other code sharing approaches. If other people need to create executors, they can just reference the executor-base library and implement the actual execution part. Therefore they don’t need to worry about the the connection implementations to the Tapas system. 
+
+## Consequences
+
+It becomes easier to change the way that the executors communicate with the rest of the system. Moreover, changes are less risky as they only need to be implemented once. It also becomes easier for other teams within the organisation to create executors as they can use the executor-base to implement the shared logic. However, using a shared library will increase the complexity of the executors. Also there needs to be a clear way to use proper versioning. Lastly, by using this library we might be making assumptions for future executors that might not hold. For example, if we want to create more lightweight executors for IoT devices we might need to create a separate base package (if the current one becomes too fat), so that the executors can stay lightweight and don’t implement unused code.

doc/architecture/decisions/0011-seperation-of-common-and-executor-base-library.md

@@ -0,0 +1,19 @@
+# 11. seperation of common and executor-base library
+
+Date: 2021-11-21
+
+## Status
+
+Accepted
+
+## Context
+
+We have two code sharing libraries, the executor-base and the common library. The executor-base implements shared logic that all executors need, but other services don't. The common library has much more wide reaching implementations, such as the implementation of the SelfValidating class. These could form a single common library, or two seperate common libraries. 
+
+## Decision
+
+There will be a separate library for common and executor-base. The libraries share different type of code, and have different reasons to change. It would not make sense to have the shared code from executors in every other service which needs access to other shared code. Services that use the code in the common library should not need to be dependent in any way on the executor-base.
+
+## Consequences
+
+Changes impact fewer services. However, this decision will increase the number of service dependencies and therefore increase complexity in managing those dependencies.