Gabriel Radureau
db09d0ace1
Audit 2026-05-02 (Tâche 6 Phase A) had identified 3 inconsistent formats across the ADR corpus : - F1 list bullets : `* Status:` / `* Date:` / `* Deciders:` (11 ADRs) - F2 bold fields : `**Status:**` / `**Date:**` / `**Authors:**` (9 ADRs) - F3 dedicated section : `## Status\n**Value** ✅` (5 ADRs) Mixed metadata names (Authors / Deciders / Decision Date / Implementation Date / Implementation Status / Last Updated) and decorative emojis on status values made the corpus hard to scan or template against. Canonical format adopted (see adr/README.md for full template) : # NN. Title **Status:** <Proposed|Accepted|Implemented|Partially Implemented| Approved|Rejected|Deferred|Deprecated|Superseded by ADR-NNNN> **Date:** YYYY-MM-DD **Authors:** Name(s) [optional **Field:** ... lines] ## Context... Transformations applied (via /tmp/homogenize-adrs.py) : - F1 list bullets → bold fields - F2 cleanup : `**Deciders:**` → `**Authors:**`, strip status emojis - F3 sections : `## Status\n**Value** ✅` → `**Status:** Value` - Strip decorative emojis from `**Status:**` and `**Implementation Status:**` - Convert any `* Implementation Status:` / `* Last Updated:` / `* Decision Drivers:` / `* Decision Date:` to bold equivalents - Date typo fix : `2024-04-XX` → `2026-04-XX` for ADRs 0018, 0019 (already noted in PR #17 but here re-applied since branch starts from origin/main pre-PR17) - Normalize multiple blank lines after header (max 1) 21 / 23 ADRs modified. 0010 and 0012 were already conform. 0011 and 0014 do not exist in the repo (cf. README index update). Body content of each ADR is preserved unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.6 KiB
2.6 KiB
Adopt interface-based design pattern
Status: Accepted Authors: Gabriel Radureau, AI Agent Date: 2026-04-02
Context and Problem Statement
We needed to choose a design pattern for dance-lessons-coach that provides:
- Good testability and mocking capabilities
- Flexibility for future changes
- Clear separation of concerns
- Dependency injection support
- Maintainability and readability
Decision Drivers
- Need for easy testing and mocking
- Desire for flexible, maintainable architecture
- Requirement for clear component boundaries
- Need for dependency injection
- Long-term evolution of the codebase
Considered Options
- Interface-based design - Define interfaces first, implement later
- Direct implementation - Implement concrete types directly
- Functional approach - Use functions and composition
- DDD-style aggregates - Domain-driven design patterns
Decision Outcome
Chosen option: "Interface-based design" because it provides excellent testability, clear contracts, flexibility for future changes, and good support for dependency injection while maintaining good readability.
Pros and Cons of the Options
Interface-based design
- Good, because excellent for testing and mocking
- Good, because clear component contracts
- Good, because flexible for future changes
- Good, because supports dependency injection well
- Good, because encourages good separation of concerns
- Bad, because slightly more boilerplate
- Bad, because can be over-engineered if taken too far
Direct implementation
- Good, because simpler and more direct
- Good, because less boilerplate
- Bad, because harder to test and mock
- Bad, because less flexible for changes
- Bad, because tighter coupling
Functional approach
- Good, because can be very clean and simple
- Good, because good for pure functions
- Bad, because less familiar in Go ecosystem
- Bad, because harder to manage state
DDD-style aggregates
- Good, because good for complex domains
- Good, because clear boundaries
- Bad, because overkill for simple services
- Bad, because more complex to implement
Links
Implementation Examples
// Good: Interface defined first
type Greeter interface {
Greet(ctx context.Context, name string) string
}
type Service struct{}
func (s *Service) Greet(ctx context.Context, name string) string {
// implementation
}
// Bad: Direct implementation without interface
type Service struct{}
func (s *Service) Greet(name string) string {
// implementation
}