ADRs #30

Merged
reynisson merged 2 commits from dev into main 2021-10-18 05:32:31 +00:00
9 changed files with 145 additions and 0 deletions

1
.adr-dir Normal file
View File

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

View File

@ -0,0 +1,19 @@
# 1. Record architecture decisions
reynisson commented 2021-10-17 22:32:45 +00:00 (Migrated from github.com)
Review

This file is added automatically by the ADR program. I don't see any harm in keeping it

This file is added automatically by the ADR program. I don't see any harm in keeping it
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).

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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 dont 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 dont need to know about each other. To guarantee data consistency we can also use a pattern like sagas.

View File

@ -30,6 +30,10 @@
<scope>runtime</scope> <scope>runtime</scope>
<optional>true</optional> <optional>true</optional>
</dependency> </dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
<dependency> <dependency>
<groupId>org.projectlombok</groupId> <groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId> <artifactId>lombok</artifactId>

18
tapas-tasks/Dockerfile Normal file
View File

@ -0,0 +1,18 @@
FROM openjdk:11 AS development
WORKDIR /opt/app
# ENV SPRING_DATASOURCE_URL=jdbc:mysql://backend-db:3306/db
COPY .mvn/ .mvn
COPY mvnw pom.xml mvnw.cmd ./
RUN apt-get clean && apt-get update && apt-get install dos2unix
RUN dos2unix mvnw
RUN ./mvnw dependency:go-offline
COPY src /opt/app/src
COPY *target /opt/app/target
CMD ["./mvnw", "spring-boot:run", "-Dspring-boot.run.jvmArguments=\"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005\"", "-Dspring.devtools.restart.enabled=true"]