What
Create Architectural Decision Records (ADRs) for each ecosystem project,
documenting the key design decisions that shaped the current architecture.
Currently only pacs_system has 2 ADRs; the other 7 projects have none.
Why
ADRs capture the why behind architectural choices. Without them, contributors
must reverse-engineer design rationale from code, or make changes that conflict
with intentional design decisions. ADRs prevent architectural regression and
accelerate onboarding for new contributors.
Where
| Repository |
Current ADRs |
Target (Initial) |
| common_system |
0 |
2-3 |
| thread_system |
0 |
2-3 |
| logger_system |
0 |
2-3 |
| container_system |
0 |
2-3 |
| monitoring_system |
0 |
2-3 |
| database_system |
0 |
2-3 |
| network_system |
0 |
2-3 |
| pacs_system |
2 |
1-2 additional |
How
ADR Template
---
doc_id: "{PREFIX}-ADR-{NNN}"
doc_title: "ADR-{NNN}: {Title}"
doc_date: "YYYY-MM-DD"
doc_status: "Accepted"
project: "{project_name}"
category: "ADR"
---
# ADR-{NNN}: {Title}
## Status
{Proposed | Accepted | Deprecated | Superseded by ADR-XXX}
## Context
{What is the issue or decision that needs to be made?}
## Decision
{What was decided and why?}
## Alternatives Considered
{What other options were evaluated?}
## Consequences
{What are the positive and negative consequences of this decision?}
Priority ADR Topics Per Project
| Project |
ADR-001 |
ADR-002 |
ADR-003 |
| common_system |
Header-only library design |
Result error handling pattern |
Value type system design |
| thread_system |
Queue architecture selection |
C++20 coroutine integration strategy |
Priority scheduling design |
| logger_system |
Decorator pattern adoption |
OpenTelemetry integration approach |
Async writer architecture |
| container_system |
SIMD optimization strategy |
Value type system design |
Type-safe container approach |
| monitoring_system |
Collector factory pattern |
Distributed tracing integration |
Metrics pipeline design |
| database_system |
Multi-backend abstraction |
ORM vs raw query design |
Connection mode architecture |
| network_system |
Facade API introduction |
Protocol modularization strategy |
Coroutine-based I/O design |
| pacs_system |
DICOM layer separation (extend existing) |
Phase-based development strategy (extend existing) |
— |
File Location
docs/adr/
├── ADR-001-{topic}.md
├── ADR-002-{topic}.md
└── ADR-003-{topic}.md
Implementation Steps
- Create
docs/adr/ directory in each project
- Write ADR-001 for each project (highest-impact decision)
- Write ADR-002 and ADR-003 for each project
- Add ADR entries to the SSOT registry (docs/README.md)
- Cross-reference ADRs from relevant ARCHITECTURE.md sections
Acceptance Criteria
Related
What
Create Architectural Decision Records (ADRs) for each ecosystem project,
documenting the key design decisions that shaped the current architecture.
Currently only pacs_system has 2 ADRs; the other 7 projects have none.
Why
ADRs capture the why behind architectural choices. Without them, contributors
must reverse-engineer design rationale from code, or make changes that conflict
with intentional design decisions. ADRs prevent architectural regression and
accelerate onboarding for new contributors.
Where
How
ADR Template
Priority ADR Topics Per Project
File Location
Implementation Steps
docs/adr/directory in each projectAcceptance Criteria
docs/adr/directory exists in all 8 projectsRelated