Architecture Decision Records¶
An ADR records one significant technical decision: the context, the options considered, what we chose, and the consequences. ADRs are short and are never rewritten after they are accepted; a later ADR supersedes an earlier one instead.
Index¶
| ADR | Title | Status |
|---|---|---|
| ADR-0001 | Record architecture decisions | Accepted |
| ADR-0002 | React and NestJS with a modular Domain-Driven Design | Accepted |
| ADR-0003 | PostgreSQL as the database | Accepted |
| ADR-0004 | Nx monorepo | Accepted |
| ADR-0005 | System module for tenant-level administration | Accepted |
| ADR-0006 | Drizzle ORM | Accepted |
| ADR-0007 | shadcn/ui on Tailwind CSS | Accepted |
| ADR-0008 | Modular monolith with extractable modules | Proposed |
| ADR-0009 | Testing tools: Jest, Vitest with Testing Library, Playwright | Accepted |
| ADR-0010 | Clean Architecture for backend and Feature-Based Architecture for frontend | Accepted |
| ADR-0011 | One PostgreSQL database per tenant | Superseded by 0012 |
| ADR-0012 | Single PostgreSQL database with shared schema multi-tenancy | Accepted |
Conventions¶
- File name:
NNNN-short-title.md, numbered in order and never reused. Start from the template. - Status:
Proposed(under discussion),Accepted,Deprecated(no longer applies),Superseded by NNNN. - Write an ADR when a decision is hard to reverse or affects more than one part of the system: language and framework, database and tenancy model, authentication, hosting, major libraries.
- Open the ADR as
Proposedin the same change that needs it; mark itAcceptedonce reviewed. - Add every ADR to the index above, with link text
ADR-NNNN.