Skip to content

Architectural Refinement - Sprint 1

Architecture Overview

Sprint 1 establishes the architectural foundation for the entire feedback system, focusing on the user management microservice and the authentication infrastructure. This architecture follows the principles of Domain-Driven Design (DDD) and microservices, enabling scalability and maintainability.

Architectural Components

User Management Microservice

The user management microservice is responsible for:

  1. Authentication: Validating credentials and generating JWT tokens
  2. User Management: CRUD operations for employees, PDMs, and administrators
  3. Authorization: Defining and verifying role-based permissions

mmd

Security Library

A shared security library will be developed to encapsulate authentication and authorization logic, allowing its reuse in other microservices.

mmd

Frontend

The frontend will be developed with Next.js, using a React component architecture and integration with the backend via a RESTful API.

mmd

Architectural Decisions

1. Stateless Authentication with JWT

Decision: Use JWT (JSON Web Tokens) for stateless authentication.

Justification:

  • Allows for horizontal scalability without the need for shared sessions
  • Facilitates integration between microservices
  • Reduces the load on the database by eliminating frequent queries for session validation

Implications:

  • Need to manage token expiration and renewal
  • Inability to invalidate individual tokens without additional implementation
  • The size of the token payload impacts the size of the requests

2. Shared Security Library

Decision: Create a shared library for security logic.

Justification:

  • Avoids code duplication between microservices
  • Ensures consistency in security implementation
  • Facilitates security updates and fixes

Implications:

  • Need to manage library versions
  • Coupling between microservices and the library
  • Need for rigorous testing to prevent regressions

3. Soft Delete for Users

Decision: Implement soft delete for user deactivation.

Justification:

  • Preserves the history of actions and relationships
  • Allows for user reactivation if necessary
  • Maintains referential integrity in the database

Implications:

  • Need to filter inactive users in queries
  • Increase in database size over time
  • Additional complexity in queries and indexes

4. Database per Microservice

Decision: Each microservice will have its own database.

Justification:

  • Data isolation and autonomy of microservices
  • Possibility to choose the most suitable database for each context
  • Reduction of single points of failure

Implications:

  • Need to manage eventual consistency between services
  • Additional complexity in queries involving data from multiple services
  • Maintenance overhead of multiple databases

Applied Architectural Patterns

1. Domain-Driven Design (DDD)

The user management microservice will follow DDD principles:

  • Entities: User as the main entity with its own identity
  • Value Objects: LoggedInUser as an immutable representation of the authenticated user
  • Aggregates: User as the aggregate root, encapsulating business rules
  • Repositories: Interfaces for aggregate persistence
  • Domain Services: Business logic that does not naturally belong to entities

2. Layered Architecture

The microservice will be structured in layers:

```mermaid block-beta columns 2 block:presentation A["Controllers"]:1 end Presentation["Presentation Layer"]:1

block:application
    B["Services"]:1
end
Application["Application Layer"]:1

block:domain
    C["Domain Objects"]:1
end
Domain["Domain Layer"]:1

block:infra
    D["Repositories"]:1
end
Infrastructure["Infrastructure Layer"]:1

Presentation ----> presentation
Application