freemo
d9e5668cec
Fixes and improvements from exhaustive audit: Consistency fixes in SKILL.md: - 'Pipe & Filter' → 'Pipe and Filter' (one stray '&' found and corrected) - 'Singleton for factory instance' → clarified to 'register factory as singleton-scoped via DI container' (less misleading wording) - Documentation Format section updated with note that SKILL.md itself is the authoritative source for related-pattern combinations Coverage fix — Related Patterns sections: - Added '## Related Patterns' to ALL 94 pattern files (was 0/94) - Each section lists 3–6 related patterns with relationship descriptions - Covers: why they're related, when to prefer one vs the other, and which are often confused SOLID principles → Creational → Structural → Behavioral → Architectural → Concurrency → Functional → Resilience → Data Access → Messaging → Testing → Error Handling → Microservice — all 13 categories covered Code verification: - Python: 0 failures (all 85 testable blocks pass) - Go: 0 failures (all 76 testable blocks pass) - JavaScript: 0 failures (all 78 testable blocks pass) - All 239 code blocks verified correct after edits Final skill state: - 108 files, 36,524 lines across 13 reference categories - 94/94 pattern files have Related Patterns sections - 2,815-line SKILL.md with 67 decision trees, 23 scenarios, 0 broken references, 0 naming inconsistencies
Data Access Patterns
Data access patterns define how application code interacts with persistent storage — databases, files, caches. They address the impedance mismatch between object-oriented domain models and relational or document-based storage, while managing concerns like identity, loading strategy, and data transfer boundaries.
Pattern Comparison
| Pattern | Purpose | Complexity | Best For |
|---|---|---|---|
| Active Record | Domain object handles its own CRUD | Low | Simple domains, rapid prototyping |
| Data Mapper | Separate mapper layer between domain and DB | High | Complex domains, clean architecture |
| Identity Map | Cache loaded objects by ID, avoid duplicates | Medium | ORM internals, unit-of-work |
| Lazy Loading | Defer data loading until first access | Medium | Object graphs with optional relations |
| DTO | Transfer data across boundaries without behavior | Low | API layers, serialization |
| Value Object | Immutable, identity-free domain values | Low | Money, coordinates, date ranges |
| Aggregate | Cluster of objects treated as a unit | High | DDD, transactional consistency |
Decision Guide
Is your domain model simple (few relations, straightforward CRUD)?
├─ Yes → Active Record
└─ No → Data Mapper + Identity Map
│
├─ Do objects have large relation graphs?
│ └─ Yes → Add Lazy Loading
│
├─ Do you pass data across layers/APIs?
│ └─ Yes → Use DTOs at boundaries
│
├─ Do you have small immutable concepts (money, email)?
│ └─ Yes → Model as Value Objects
│
└─ Do you need transactional consistency across multiple objects?
└─ Yes → Define Aggregates
Key Principles
- Separate concerns — Domain logic should not depend on storage mechanics.
- Manage identity explicitly — Know when two references point to the same entity.
- Load only what you need — Eager loading wastes resources; lazy loading risks N+1.
- Protect boundaries — Don't leak domain objects into API responses (use DTOs).
- Design for consistency — Aggregates define transactional boundaries.