Architecture Documentation

In the past (until this last commit) we used a Monolithic Architecture and inside it, we used Clean Architecture for development. After a while, when the app was in a stable state, we decide to migrate the Architecture from Monolith to Microservices by following Strangler application pattern. According to the Microservices architecture, we extract some services by using aggregate and BC concepts of DDD and develop them separately using Clean Architecture.

TaskoMask Development Architecture

At the first step of refactoring the architecture from Monolithic into Microservices, we prepared the development architecture like below diagram and then considered the monolith as a single service, so we were able to extract each services step by step.

🔴Attention: We decided to separate each services into Read and Write parts. It helps us to keep the things more clean and maintainable and easy to change. Also, we can decide how to scale a service in production by considering the loads on its Read and Write side.

You can browse the code related to the first step from this commit.

TaskoMask Deployment Architecture

After extracting all services and making communication between them and implementing API Gateways, observability, monitoring, etc. the architecture is like following diagram:

Developing services using Clean Architecture

As you see in the TaskoMask development architecture diagram, each service is developed over Clean Architecture like following diagram:

So generally we have the following layers in each service:

• Domain
• Infrastructure
• Application
• API
• Tests

Domain

This layer contains the domain model for the services, we use Rich domain model following DDD concepts for the Write side and Anemic domain model to be used in the Read side.

Infrastructure

Here we config all infrastructure stuff like Database and other cross-cutting concerns like object mapper, mediator, etc. Also, general configuration come from building blocks like message bus, logging, etc.

Application

In this layer we mainly implement use cases. We use the benefits of Use Case Driven Development approach and vertical slice architecture. If you are not familiar with these approaches, we recommend you to have a look on following posts:

• Vertical Slice Architecture
• Feature Folder Structure
• Use Case Driven Development by Valentina Cupać

API

This is the Presentation part of the services and contains a web API project. These API services are not accessible directly from the outside world and just can be used through API Gateways.

Tests

It contains all Unit & Integration for the service.