Architecture Design Critique

Assess how well a codebase separates core domain logic from infrastructure concerns. Three phases with distinct mindsets to prevent jumping to recommendations without understanding what exists.

Key questions answered: Can you swap your database without rewriting business logic? Can you test domain rules without spinning up external services? Will the architecture support 10x growth?

Ports & Adapters in 30 Seconds

The core idea: your domain logic (business rules, core algorithms) should never directly depend on infrastructure (databases, HTTP, file systems, external APIs). Instead:

• Ports: Interfaces that define what the domain needs (e.g., UserRepository, PaymentGateway)
• Adapters: Implementations that connect ports to real infrastructure (e.g., PostgresUserRepository, StripePaymentGateway)

Dependencies point inward: adapters depend on ports, never the reverse. This makes the core testable, portable, and resistant to infrastructure churn.

Output Structure

Before starting, ask the user for an output directory (e.g., ./docs/architecture/ or ./reviews/).