1.6 KiB
1. 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.
Decision
The system will follow the Microservice architecture.
The Microservices architecture suits our system's driving architectural characteristics particularly well. Scalability and fault tolerance are two of the systems top 3 driving characteristics and elasticity and evolvability are two of the systems other driving characteristics. These are all characteristics that the Microservices architecture excels at. Furthermore, none of our system's driving characteristics is hindered by the Microservices architecture (none of them have below 3 stars out of 5).
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.
Using a distributed architecture makes managing transactions more complex. This means that we could need to use sagas to manage distributed transactions. So far the only workflow that would require transactions between domains would be the deletion of tasks.