Solid Ddd
Keep SOLID and DDD tactical patterns in context whenever you or your agent change non-documentation code, so refactors stay cohesive and domain-shaped.
Overview
solid-ddd is a journey-wide agent skill that applies language-agnostic SOLID and DDD tactical patterns whenever a solo builder implements or reviews non-documentation code.
Install
npx skills add https://github.com/fearovex/claude-config --skill solid-dddWhat is this skill?
- Language-agnostic SOLID catalog with concrete do/don't examples
- DDD tactical patterns for entities, value objects, aggregates, and repositories
- Auto-loaded for non-documentation code changes via sdd-apply in fearovex/claude-config
- SRP violation signals: unrelated change reasons (schema vs email templates)
- Reference format meant for both implementation and review sessions
- SRP do/don't example trio: OrderService split into OrderRepository, OrderNotifier, DiscountCalculator
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your agent keeps merging persistence, notifications, and pricing into one class because nothing enforces single-responsibility and clear domain boundaries during edits.
Who is it for?
Solo builders using fearovex-style agent configs who want SOLID and DDD reminders on every non-doc code change and during reviews.
Skip if: Pure documentation or markdown-only edits, or greenfield projects where you have not chosen any modular architecture yet—skip auto-load until you write real code.
When should I use this skill?
Always loaded for non-documentation code changes via sdd-apply; also when writing or reviewing any class, module, domain object, service, or repository.
What do I get? / Deliverables
Code changes align with SOLID and DDD tactical patterns—separated repositories, notifiers, and calculators—so modules have one reason to change and domain language stays consistent.
- SOLID-aligned class and module structure
- DDD-shaped entities, repositories, and services
- Review feedback grounded in tactical pattern violations
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Split a bloated OrderService into repository, notifier, and discount calculator before adding payment webhooks.
Model external billing as an anti-corruption layer instead of leaking provider DTOs into core entities.
Flag a PR where email templates and DB schema changes live in the same class—classic SRP violation signal from the skill.
Refactor a hotfix path in production code while keeping aggregate boundaries intact.
Sketch bounded contexts in a spike so prototype code does not cement the wrong aggregates.
How it compares
Embedded design reference for agents, not a standalone code formatter or test runner.
Common Questions / FAQ
Who is solid-ddd for?
Developers and agent users who want consistent SOLID and DDD tactical guidance across languages whenever implementation or review touches classes, modules, or domain objects.
When should I use solid-ddd?
Use it journey-wide during Build when modeling services, during Ship when reviewing PRs for SRP violations, and during Operate when refactoring production modules without breaking domain boundaries.
Is solid-ddd safe to install?
It is reference text without inherent network calls; still review the Security Audits panel on this Prism page for the parent claude-config repository.
SKILL.md
READMESKILL.md - Solid Ddd
# solid-ddd > Language-agnostic catalog of SOLID design principles and Domain-Driven Design tactical patterns with concrete do/don't examples. **Triggers**: Always loaded for non-documentation code changes. Load when writing or reviewing any class, module, domain object, service, or repository. Applicable across all languages and frameworks. --- ## Patterns ### SOLID Principles --- #### SRP — Single Responsibility Principle A class, module, or function has exactly one reason to change. One unit = one concern. **DON'T** — one class handles both order persistence and email notification: ```typescript // [Illustrative — TypeScript] class OrderService { save(order: Order): void { /* writes to DB */ } sendConfirmationEmail(order: Order): void { /* sends email */ } calculateDiscount(order: Order): number { /* discount logic */ } } ``` **DO** — each class owns one responsibility: ```typescript // [Illustrative — TypeScript] class OrderRepository { save(order: Order): void { /* DB only */ } } class OrderNotifier { sendConfirmation(order: Order): void { /* email only */ } } class DiscountCalculator { calculate(order: Order): number { /* pricing only */ } } ``` **Signal — SRP violated**: the class has multiple unrelated reasons to change (schema change AND email template change affect the same file). --- #### OCP — Open/Closed Principle A unit is open for extension, closed for modification. Add behavior by adding code, not by editing existing code. **DON'T** — every new payment method requires editing the same function: ```typescript // [Illustrative — TypeScript] function processPayment(type: string, amount: number) { if (type === 'credit') { /* ... */ } else if (type === 'paypal') { /* ... */ } // Adding 'crypto' forces editing this function } ``` **DO** — new behavior is added by adding a new implementation: ```typescript // [Illustrative — TypeScript] interface PaymentProcessor { process(amount: number): void; } class CreditProcessor implements PaymentProcessor { process(amount) { /* ... */ } } class PaypalProcessor implements PaymentProcessor { process(amount) { /* ... */ } } // Adding crypto: create CryptoProcessor — no existing code touched ``` **Signal — OCP violated**: adding a new variant requires touching a central switch/if chain that already exists. --- #### LSP — Liskov Substitution Principle Subtypes must be substitutable for their base types without altering correctness. A subclass must honor the contract of its parent. **DON'T** — subclass breaks the parent contract by throwing where parent succeeds: ```typescript // [Illustrative — TypeScript] class Rectangle { setWidth(w: number) { this.width = w; } } class Square extends Rectangle { setWidth(w: number) { this.width = w; this.height = w; } // Breaks area contract } ``` **DO** — prefer composition or a shared interface with separate implementations: ```typescript // [Illustrative — TypeScript] interface Shape { area(): number; } class Rectangle implements Shape { area() { return this.width * this.height; } } class Square implements Shape { area() { return this.side * this.side; } } ``` **Signal — LSP violated**: calling code needs to check the concrete type before using the abstraction (`if (shape instanceof Square)`). --- #### ISP — Interface Segregation Principle Clients must not be forced to depend on methods they do not use. Prefer narrow, focused interfaces over fat ones. **DON'T** — one fat interface forces every implementor to stub unused methods: ```typescript // [Illustrative — TypeScript] interface Worker { work(): void; eat(): void; // Robots don't eat sleep(): void; // Robots don't sleep } class RobotWorker implements Worker { work() { /* real logic */ } eat() { throw new Error('Not supported'); } // fo