# ADR 0002 — Modular Monolith

**Status:** Accepted

## Context

AWP needs strong internal boundaries without inheriting Overdeck's accidental collection of unrelated tools or prematurely paying distributed-system costs.

## Decision

Start the control plane as a modular monolith. Domain/application/provider boundaries are explicit and enforced by dependency rules. Separate deployables exist for gateway, control plane and web, but control-plane domain modules remain one coherent application until evidence justifies extraction.

## Consequences

- one transactional authority and simpler development/operations;
- package/module fitness rules are mandatory from I0;
- provider SDKs stay in adapters;
- domain modules communicate through explicit APIs/events rather than arbitrary table/import access.

## Rejected Alternatives

- microservices-first;
- one undifferentiated package organized only by HTTP routes;
- carrying legacy Overdeck module identities forward.

## Increment Realization

I0 creates the package/dependency skeleton. I1 proves boundaries across Project/Factory/Change/Review. Service extraction is a later explicit Decision, not a roadmap assumption.