Skip to content

Components (C4 Level 3)

This page describes the third level of the C4 model - the Component diagram. It shows the internal components of the key containers in the Switchain Services system. For this example, we'll focus on the Wallets API and Wallets Worker containers.

Wallets API Components

The Wallets API container consists of the following components:

API Layer

  • API Server (Elysia): Handles HTTP requests and routes them to the appropriate handlers
  • Wallet Controller (TypeScript): Handles wallet-related API endpoints
  • Transaction Controller (TypeScript): Handles transaction-related API endpoints
  • User Controller (TypeScript): Handles user-related API endpoints

Service Layer

  • Wallet Service (TypeScript): Implements wallet business logic
  • Transaction Service (TypeScript): Implements transaction business logic
  • User Service (TypeScript): Implements user business logic
  • Queue Service (BullMQ): Publishes jobs to Redis queues
  • Blockchain Service (TypeScript): Interacts with blockchain networks

Data Access Layer

  • Wallet Repository (Prisma): Data access layer for wallets
  • Transaction Repository (Prisma): Data access layer for transactions
  • User Repository (Prisma): Data access layer for users

External Dependencies

  • Database (PostgreSQL): Stores user data, transactions, and system configuration
  • Redis: Used for caching and job queues
  • Blockchain Networks: Various blockchain networks

Key Interactions

  1. API Routing:

    • API Server routes wallet requests to Wallet Controller
    • API Server routes transaction requests to Transaction Controller
    • API Server routes user requests to User Controller
  2. Controller-Service Interactions:

    • Wallet Controller uses Wallet Service
    • Transaction Controller uses Transaction Service
    • User Controller uses User Service
  3. Service-Repository Interactions:

    • Wallet Service uses Wallet Repository
    • Wallet Service uses Blockchain Service
    • Wallet Service uses Queue Service
    • Transaction Service uses Transaction Repository
    • Transaction Service uses Blockchain Service
    • Transaction Service uses Queue Service
    • User Service uses User Repository
  4. Data Access:

    • Wallet Repository reads from and writes to Database
    • Transaction Repository reads from and writes to Database
    • User Repository reads from and writes to Database
    • Queue Service publishes jobs to Redis
    • Blockchain Service reads from Blockchain Networks

Wallets Worker Components

The Wallets Worker container consists of the following components:

Job Processing Layer

  • Job Processor (BullMQ): Processes jobs from Redis queues
  • Wallet Job Handler (TypeScript): Handles wallet-related background jobs
  • Transaction Job Handler (TypeScript): Handles transaction-related background jobs

Service Layer

  • Wallet Service (TypeScript): Implements wallet business logic
  • Transaction Service (TypeScript): Implements transaction business logic
  • Blockchain Service (TypeScript): Interacts with blockchain networks

Data Access Layer

  • Wallet Repository (Prisma): Data access layer for wallets
  • Transaction Repository (Prisma): Data access layer for transactions

External Dependencies

  • Database (PostgreSQL): Stores user data, transactions, and system configuration
  • Redis: Used for caching and job queues
  • Blockchain Networks: Various blockchain networks

Key Interactions

  1. Job Routing:

    • Job Processor routes wallet jobs to Wallet Job Handler
    • Job Processor routes transaction jobs to Transaction Job Handler
  2. Handler-Service Interactions:

    • Wallet Job Handler uses Wallet Service
    • Transaction Job Handler uses Transaction Service
  3. Service-Repository Interactions:

    • Wallet Service uses Wallet Repository
    • Wallet Service uses Blockchain Service
    • Transaction Service uses Transaction Repository
    • Transaction Service uses Blockchain Service
  4. Data Access:

    • Wallet Repository reads from and writes to Database
    • Transaction Repository reads from and writes to Database
    • Job Processor consumes jobs from Redis
    • Blockchain Service sends transactions to Blockchain Networks

Hexagonal Architecture Implementation

Both the Wallets API and Wallets Worker follow the hexagonal architecture pattern, which is organized into three main layers:

Domain Layer

  • Contains the core business logic and domain entities
  • Independent of external frameworks and technologies
  • Defines interfaces that will be implemented by the infrastructure layer

Application Layer

  • Orchestrates the flow of data to and from the domain layer
  • Contains use cases and application services
  • Depends on the domain layer but not on the infrastructure layer

Infrastructure Layer

  • Implements the interfaces defined by the domain layer
  • Contains adapters for external systems (database, blockchain, etc.)
  • Depends on both the domain and application layers

This architecture ensures a clear separation of concerns and makes the system more maintainable and testable.

Package Structure

The components are organized into packages following the hexagonal architecture:

packages/wallets/
├── domain/
│   ├── entities/
│   ├── repositories/
│   ├── services/
│   └── value-objects/
├── application/
│   ├── wallet/
│   ├── walletAddress/
│   ├── transaction/
│   ├── services/
│   ├── utxo/
│   ├── tron/
│   └── solana/
└── infrastructure/
    ├── repositories/
    ├── services/
    └── adapters/

Next Steps

After understanding the components that make up the containers, you can dive deeper into the Code level to see specific implementation details and patterns used in the codebase.