Skip to content
motmaina docs

Module Map

Module Map

Section titled “Module Map”

Purpose

Section titled “Purpose”

This page explains how the current backend is divided into modules and what each module is responsible for.

The backend is not organized as one large service. It is split into feature modules and infrastructure modules that are wired together in the root application module.

Current Module Groups

Section titled “Current Module Groups”

The currently visible modules can be grouped into two categories:

  • feature modules
  • infrastructure and support modules

Feature Modules

Section titled “Feature Modules”

These modules expose business-facing behavior or domain APIs.

1. Auth Module

Section titled “1. Auth Module”

The auth module is currently the strongest business module in the backend.

It is responsible for:

  • guest token generation
  • refresh token rotation
  • OTP-based phone verification
  • registration
  • logout
  • token scope handling
  • global route protection through the auth guard

Key implementation pieces:

  • AuthController
  • AuthService
  • JWT config and JWT strategy
  • auth decorators and guards
  • auth DTOs, mappers, and typed auth payloads

Architecturally, this module is important because it does not only provide endpoints. It also influences the entire backend security model through:

  • APP_GUARD
  • route-level public/private decorators
  • JWT scope-aware access rules

2. Consultants Module

Section titled “2. Consultants Module”

The consultants module handles consultant-related API behavior.

It currently provides:

  • paginated consultant listing
  • consultant detail retrieval
  • structured response handling
  • translation-aware not-found behavior

The current module shape suggests it is intended to become the main domain entry point for consultant-focused APIs.

Key implementation pieces:

  • ConsultantsController
  • ConsultantsService

3. Reference Module

Section titled “3. Reference Module”

The reference module provides lookup-style reference data to clients.

At the moment, it exposes category-like data for:

  • consultation categories
  • clinic or service categories

This module is useful as a read-only support API that feeds frontend selectors, browse pages, and public discovery flows.

Key implementation pieces:

  • ReferenceController
  • ReferenceService

4. Health Module

Section titled “4. Health Module”

The health module exposes runtime health checks and is operational rather than business-facing.

It currently provides:

  • disk health checks
  • memory health checks
  • database health checks through Prisma

This module should be thought of as an infrastructure-facing API surface used by deployment, monitoring, and diagnostics.

Key implementation pieces:

  • HealthController
  • Terminus integration
  • health configuration

Infrastructure and Support Modules

Section titled “Infrastructure and Support Modules”

These modules are foundational and support the feature modules.

5. Database Module

Section titled “5. Database Module”

The database module provides the global Prisma integration layer.

It is responsible for:

  • instantiating Prisma client access
  • sharing Prisma through Nest dependency injection
  • managing connection lifecycle
  • exposing a reusable persistence service to feature modules

Key implementation pieces:

  • PrismaModule
  • PrismaService

This module is infrastructural and shared by multiple business modules.

6. Messaging Module

Section titled “6. Messaging Module”

The messaging module provides outbound communication capabilities.

It currently handles:

  • SMS sending
  • WhatsApp sending
  • environment-aware messaging enablement
  • HTTP-based integration with external messaging services

This is a support module used by other domains, especially auth flows that rely on OTP delivery.

Key implementation pieces:

  • MessagingService
  • HttpModule
  • environment-driven provider configuration

7. I18n Module

Section titled “7. I18n Module”

The i18n module provides translation and locale-resolution support across the backend.

It is responsible for:

  • loading translation files
  • resolving locale from query parameters or request headers
  • exposing translation helpers to services
  • supporting localized success and error messages

Key implementation pieces:

  • I18nConfigModule
  • TranslationService

This is a global support module and is used by feature modules such as auth, consultants, and reference.

8. Development Module

Section titled “8. Development Module”

The development module is conditionally loaded only in development mode.

Its current responsibility is:

  • serving local coverage reports through a static route

This indicates a clear separation between production runtime behavior and development-only tooling support.

Dependency Flow Between Modules

Section titled “Dependency Flow Between Modules”

The current module graph suggests the following common dependency directions:

  • feature modules depend on PrismaModule
  • feature modules may depend on I18nConfigModule indirectly through exported services
  • auth depends on messaging for OTP delivery
  • health depends on Prisma for database checks
  • development remains isolated and environment-specific

In simple terms:

  • Database is the shared persistence base
  • I18n is the shared language base
  • Messaging is the shared outbound communication base
  • feature modules compose business behavior on top of those foundations

Module Boundary Interpretation

Section titled “Module Boundary Interpretation”

The current boundaries are relatively clean:

  • auth owns identity and access-related flows
  • consultants owns consultant-facing read APIs
  • reference owns lightweight lookup data
  • health owns operational visibility
  • messaging owns external message delivery
  • database owns persistence infrastructure
  • i18n owns localization support

This is a good sign for future backend growth because new business modules can be added without collapsing all concerns into one shared service.

What Is Not Yet Visible

Section titled “What Is Not Yet Visible”

The current module map also shows what has not yet fully emerged in the new backend:

  • appointments module
  • consultations module
  • payments module
  • courses module
  • notifications module
  • customer module

These domains exist in the broader platform and legacy database, but they are not yet represented as first-class Nest modules in the currently visible backend source.

That means the backend is still in an expansion phase, not at final domain completeness.

Section titled “Recommended Documentation Framing”

For documentation purposes, the module map should currently be described as:

  • a modular NestJS backend with a strong auth foundation
  • a small but growing set of feature modules
  • shared infrastructure modules for database, localization, messaging, and health
  • clearly prepared for future domain expansion

Summary

Section titled “Summary”

The current module layout already demonstrates a healthier backend structure than the legacy monolithic pattern:

  • responsibilities are separated
  • infrastructure concerns are centralized
  • business modules are easier to reason about
  • future domains can be added incrementally

This makes the module map one of the clearest signs that the new backend is being designed for maintainability and long-term extensibility.