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)
938 B
938 B
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