Skip to content

Refactor: Reorganize Frontend Monorepo into Domain-Driven Modules #483

Description

@Smartdevs17

Context

The frontend codebase has grown organically. Components, hooks, and utilities are spread across folders without clear domain boundaries.

Current Limitation/Problem

Feature code is scattered across generic directories (components/, hooks/, utils/). Related code for a feature (e.g., payments) is not colocated, making navigation and maintenance difficult.

Expected Outcome

A domain-driven directory structure where each business domain (payments, merchants, wallets, analytics, settings) is a self-contained module with its own components, hooks, API calls, and types.

Acceptance Criteria

  • Define domain modules: payments, merchants, wallets, analytics, settings, developers
  • Each domain has: components/, hooks/, api/, types/, pages/ subdirectories
  • Shared/common code in @/shared/ or @/ui/
  • Barrel exports per domain module
  • Imports use domain aliases (e.g., @payments/hooks/usePaymentList)
  • All existing imports updated to new structure
  • No circular dependencies between domains
  • Lint rule enforcing domain boundary rules
  • Migration guide in CONTRIBUTING.md

Technical Scope

  • frontend/src/domains/{payments,merchants,wallets,analytics,settings,developers}/
  • frontend/src/shared/ - shared utilities and UI primitives
  • frontend/src/ui/ - design system components
  • ESLint plugin for boundary enforcement
  • Codemod script for automated import migration
  • Edge cases: cross-domain shared state, global providers

Metadata

Metadata

Assignees

Labels

200-points200 point issueStellar WaveIssues in the Stellar wave programdrips-waveIssues in the Drips Wave programhighHigh complexity issue

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions