Bernt
eab9da0100
- 8 commands (CreateFieldSession, CreateMission, RegisterArtifact, CreateObservation, CreateDecisionCase, ApproveDecision, StartReview, CompleteReview) - 4 handlers with validation and orchestration - Result<T, E> pattern — explicit success/failure, no exceptions - End-to-end test: Session → Mission → DecisionCase → Approval - 3 tests proving full flow works in memory - ADR-007: Command/Result Pattern Acceptance Criteria: ✅ CreateFieldSession → CreateMission → CreateDecisionCase → ApproveDecision ✅ Without PostgreSQL, Redis, S3, API, HTTP, UI ✅ Business logic verified before infrastructure attached Next: PR-003 — PostgreSQL adapters (swap InMemory → Postgres)
39 lines
938 B
Markdown
39 lines
938 B
Markdown
# ADR-007: Command/Result Pattern
|
|
|
|
## Status
|
|
Accepted
|
|
|
|
## Context
|
|
We need a clear way to express intent to change state, execute business operations, and handle failures without exceptions.
|
|
|
|
## Decision
|
|
Use Command/Result pattern:
|
|
|
|
- **Command**: Plain object (DTO) containing all data needed to execute
|
|
- **Handler**: Contains orchestration logic, calls domain factories
|
|
- **Result**: Explicit success/failure, no exceptions for business errors
|
|
|
|
```
|
|
CreateMissionCommand
|
|
↓
|
|
CreateMissionHandler
|
|
↓
|
|
Result<MissionCreatedResult>
|
|
```
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
- Clear intent: commands are named after use cases
|
|
- Testable: handlers are pure functions with injected repositories
|
|
- No exceptions for business logic
|
|
- Audit trail: commands can be logged
|
|
- Async-friendly
|
|
|
|
### Negative
|
|
- More boilerplate than direct service calls
|
|
- Need to handle Result type at every call site
|
|
|
|
## Related
|
|
- ADR-006: In-Memory Adapters for Testing
|