ADR-001: Modular Monolith Architecture¶

Status¶

Accepted

Context¶

We need to decide on the architecture style for GrinSystem - a SaaS ERP for food production companies.

Constraints: - Small team (3-7 developers) - 6-month MVP timeline - Need for clear module boundaries - Future possibility of scaling individual modules - Domain complexity (recipes, production, warehouse, traceability)

Decision¶

We will build GrinSystem as a modular monolith with these characteristics: - Single deployable unit (one FastAPI application) - Clear bounded contexts as modules - Event-driven communication between modules (in-process dispatcher; Kafka deferred until module extraction) - Shared database with logical separation - Each module follows DDD layered architecture

Consequences¶

Positive¶

• Simpler deployment and operations (one service)
• Faster development iterations
• Transactions across modules possible
• Easier debugging and tracing
• Lower infrastructure cost initially
• Team can focus on business logic, not distributed systems

Negative¶

• All modules scale together (no independent scaling)
• Deployment requires full system restart
• Module boundary discipline required
• Future extraction to microservices requires work

Neutral¶

• Module boundaries must be enforced by convention, not infrastructure
• Team must maintain discipline on module communication

Alternatives Considered¶

References¶

• Modular Monolith Primer
• Build Modular Monoliths