Ddd Software Architecture

• Check npm for existing libraries that solve the problem
• Evaluate existing services/SaaS solutions
• Consider third-party APIs for common functionality

Architecture and Design

• Clean Architecture & DDD Principles:
  • Follow domain-driven design and ubiquitous language
  • Separate domain entities from infrastructure concerns
  • Keep business logic independent of frameworks
  • Define use cases clearly and keep them isolated
• Naming Conventions:
  • AVOID generic names: utils, helpers, common, shared
  • USE domain-specific names: OrderCalculator, UserAuthenticator, InvoiceGenerator
  • Follow bounded context naming patterns
  • Each module should have a single, clear purpose
• Separation of Concerns:
  • Do NOT mix business logic with UI components
  • Keep database queries out of controllers
  • Maintain clear boundaries between contexts
  • Ensure proper separation of responsibilities

Anti-Patterns to Avoid

• NIH (Not Invented Here) Syndrome:
  • Don't build custom auth when Auth0/Supabase exists
  • Don't write custom state management instead of using Redux/Zustand
  • Don't create custom form validation instead of using established libraries
• Poor Architectural Choices:
  • Mixing business logic with UI components
  • Database queries directly in controllers
  • Lack of clear separation of concerns
• Generic Naming Anti-Patterns:
  • utils.js with 50 unrelated functions
  • helpers/misc.js as a dumping ground
  • common/shared.js with unclear purpose
• Remember: Every line of custom code is a liability that needs maintenance, testing, and documentation

Code Quality

• Proper error handling with typed catch blocks
• Break down complex logic into smaller, reusable functions
• Avoid deep nesting (max 3 levels)
• Keep functions focused and under 50 lines when possible
• Keep files focused and under 200 lines of code when possible