CryptoMonitor Report

Once identified the domain name, the next step has been to define the Ubiquitous Language used by the team. In this phase, the key concepts related to the domain under analysis are identified. Subsequently, a glossary of terms and their definitions is created, establishing a shared language for all project stakeholders.

Here are listed the requirements identified during the analysis phase. They are divided into system, business and functional requirements. To enforce the analysis, the requirements are also linked to the use cases and user stories, providing also a detail description of them.

The knowledge crunching session was conducted using the Event Storming approach, that facilitates collaboration between developers and domain experts to explore and define the project’s domain. By utilizing color-coded sticky notes, the team iteratively identifies key elements, including actors, domain events, commands and views/read models, ensuring a comprehensive understanding of the system’s behavior and requirements. The steps followed during the Event Storming session are described as follows, until to the production of the context map.

After the Event Storming session, the team identified the Bounded Contexts that will be part of the system. Each Bounded Context is a boundary within which a domain model is defined and applicable. For each of them, the team linked the relative ubiquitous language, commands and domain events. The Bounded Contexts identified are:

At the end, after the identification of the Bounded Contexts, the team produced the Context Map that shows the relationships between the contexts. Thanks to a careful analysis, the team decided to regroup the Watchlist, Wallet and User contexts under one Bounded Context called User Management Context. This because the three contexts are strictly related to the user and his data. Here is the Context Map:

Customer-Supplier relationship between Bounded Contexts:

Conformist releationship between Bounded Contexts:

For the CryptoMonitor system, the team chose a microservices architecture. The microservices architecture is an architectural style that structures an application as a collection of services that are loosely coupled, highly maintainable, and independently deployable. Each service is responsible for a specific business capability and can be developed, deployed, and scaled independently.

The system has been divided into the following microservices following the bounded context:

The Vue-frontend and the Event-dispatcher microservices doesn’t appear in the bounded context analysis. The first-one because is dedicated only to the frontend and the second-one because is a simple orchestrator between the frontend and the other microservices. However, the team decided to include them in the architecture as a microservices to have a more clear and complete view of the system and also to permit the scalability of the entire system.

The architecture of the system is shown in the following diagram:

Each microservice interacts with the others through RESTful APIs. The Vue-frontend microservices also use WebSockets(Socket.io) to communicate with the event-dispatcher microservice to receive real-time data.

The team decided to not use an API Gateway in the architecture to avoid unecessary complecity and to keep the system as simple as possible.

For each microservice, the team adopted an hexagonal architecture, except for the Vue-frontend microservice that is a Single-Page Application (SPA). The hexagonal architecture is an architectural style that separates the application into three main layers:

In the following sections is provided a detailed description of all the microservices and their hexagonal architecture.

The team have selected the MIT License for this project due to its highly permissive terms. This license allows for unrestricted use, modification, and distribution of the software, with minimal limitations. The MIT License provides the flexibility needed for both individual contributors and corporate entities to utilize our software while maintaining appropriate legal protections.

It has been decided to adopt the Semantic Versioning (SemVer) scheme for versioning the software. SemVer consists of three numbers separated by periods: MAJOR.MINOR.PATCH. The MAJOR version is incremented for incompatible changes, the MINOR version is incremented for backward-compatible changes, and the PATCH version is incremented for backward-compatible bug fixes.

To manage the process, the team decided to use the Git Sensitive Semantic Versioning Gradle Plugin, configured with the Conventional Commit Strategy for Git Sensitive Semantic Versioning Gradle Plugin. This approach has allowed to maintain a consistent versioning strategy across the project, and to automate the versioning process based on the commit messages.

The software is released via CI through semantic-release that automatically determines the next version number based on the commit messages and releases the software on GitHub.

It has been implemented a structured branching strategy for this project to maintain code quality and streamline development workflows.

It has been configured Git hooks using Husky to automate and enforce certain checks before commits and pushes. Husky allows to easily manage Git hooks and ensure that our codebase maintains high standards.

The configuration includes the following hooks:

The pre-commit hook runs before committing, allowing code checks (e.g., linters or formatters). The commit-msg hook runs after the commit message is entered, enforcing message format or content rules.

The configuration is different between Kotlin and Typescript projects, since they use different tools for code quality checks.

(Code for Kotlin Projects - commit-msg)

(Code for Typescript Projects - commit-msg)

(Code for Kotlin Projects - pre-commit)

(Code for Typescript Projects - pre-commit)

Three templates were created to standardize the creation of new microservices. The templates are template-for-vue-js, template-for-kotlin, and template-for-typescript.

Each template includes a standardized project structure, configuration files, and build scripts to ensure consistency across microservices. The templates are designed to streamline the development process, reduce setup time, and maintain a high level of code quality.

Since the project consists of multiple microservices, each service is developed, built, and deployed independently. To ensure a consistent and automated build process, Gradle is used as the primary build tool for both Kotlin and TypeScript microservices, with npm scripts handling specific tasks for TypeScript services.

At the purpose of making the project more reliable and maintainable, various actions with GitHub Actions has been implemented. The main actions are:

The team developed various shell scripts to automatize and help our work to develop this microservice application.

These scripts are created for both Windows and Unix environments, with .ps1 for PowerShell and .sh for shell scripts. The scripts are:

Containerization, facilitated by Docker, plays a crucial role in efficiently isolating and distributing applications. Docker containers encapsulate everything needed to run an application, ensuring consistency across various environments. This approach simplifies distribution, versioning, and dependency management, enhancing the overall portability of applications.

In the microservice architecture of the system, each microservice is containerized with its own Dockerfile, enabling independent deployment and scaling. This modular approach allows for isolated development, testing, and production environments while maintaining consistency across the development lifecycle.

To make the development process more efficient and maintainable, the team has implemented a comprehensive documentation strategy. The documentation is built using AsciiDoc, a lightweight markup language that allows for easy content creation and formatting. In the Documentation Repository, the team has implemented a GitHub Actions workflow to build and deploy the documentation automatically. The workflow is triggered on pushes to the main branch and can also be manually triggered. It consists of two jobs: build and deploy.

The build job checks out the repository, installs necessary packages, sets up Ruby, installs Ruby gems, builds the documentation, and uploads the generated documentation as an artifact.

The deploy job checks out the repository, switches to the gh-pages branch, downloads the documentation artifact, imports the GPG key, and commits and pushes the updated documentation to the gh-pages branch.

The page is then built by GitHub Pages and made available at the CryptoMonitor Documentation URL.

The team implemented a Docker-based deployment approach that allows for both local development and production scenarios.

The deployment of the architecture follows a containerized microservices pattern, where each component runs in its own Docker container. The application consists of the following services:

The team decided to maintain two separate Docker Compose configurations for different deployment scenarios:

The deployment utilizes two distinct Docker networks:

The deployment implements dependency management to ensure services start in the correct order. For example, the frontend depends on the event-dispatcher, which depends on other services.

Each service includes health checks that verify its operational status before dependent services are started:

This approach prevents cascading failures where dependent services start before their prerequisites are fully operational.

It has been used the Docker Compose’s anchors and extensions feature to define reusable configuration blocks, making the configuration of the project DRY and easier to maintain:

These environment variables are then injected into each service:

Sensitive configuration values like JWT_SIMMETRIC_KEY and COINGECKO_API_KEY are provided through environment variables loaded from a .env file, which is not committed to version control for security reasons.

Each service exposes a /health endpoint that can be used for monitoring. In a production environment, these endpoints can be integrated with monitoring tools to provide alerts and visualization of system health.

The project’s principal academic value lies in the successful integration of multiple software engineering paradigms. We implemented a microservices architecture following domain-driven design principles, establishing clear bounded contexts with appropriate separation of concerns. This architectural approach provided practical insights into the theoretical concepts discussed throughout our coursework. The containerized deployment strategy using Docker demonstrates our understanding of contemporary deployment methodologies, while the implementation of CI/CD pipelines using GitHub Actions reflects our application of DevOps principles. These technical achievements were complemented by our methodological approach, utilizing event storming techniques and agile practices to systematically address the complexity inherent in the cryptocurrency domain.

The academic nature of this project allowed us to confront and resolve challenges that exemplify core software engineering problems. The cryptocurrency domain presented significant complexity in terms of business rules and terminology, requiring rigorous domain analysis. Our response—conducting thorough event storming sessions and developing a comprehensive ubiquitous language—demonstrates the practical application of domain modeling techniques. The communication patterns between microservices represented a fundamental architectural challenge. Our solution implemented an event-dispatcher service as an orchestrator, illustrating the application of design patterns to solve architectural problems. Similarly, the deployment complexities we faced required thoughtful consideration of service dependencies and health monitoring, resulting in a Docker Compose configuration that addresses these concerns systematically. Testing distributed systems presented methodological challenges that are rarely addressed in simpler academic exercises. By implementing standardized test pipelines across different programming languages, we developed practical experience with testing strategies for distributed architectures.

This project has transformed theoretical knowledge into practical understanding across multiple dimensions of software engineering. We have gained empirical insights into the relationship between domain modeling and architecture design, experiencing how theoretical concepts manifest in practical implementation. The management of complexity through microservices architecture has provided concrete experience with the benefits and challenges of this approach. The implementation of automation throughout the development lifecycle has demonstrated its value in ensuring consistent quality and productivity. Working in a multi-language environment has provided practical experience with maintaining coherence across diverse technological components. Perhaps most significantly, we have developed practical understanding of deployment and monitoring techniques for distributed systems.

While the current implementation satisfies the project requirements, several areas warrant further technical investigation in an academic context:

These improvements would provide valuable opportunities to apply advanced software engineering concepts and further explore the technical challenges inherent in distributed systems at scale.

In conclusion, this project has demonstrated the application of software process engineering principles in creating a robust, maintainable, and deployable software system. The experience has reinforced our understanding of modern software development practices and prepared us for the challenges of professional software engineering in complex domains.