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
|