mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-18 06:56:59 +03:00
Magnus HedemarkandGitHub
1037324c2a
* feat: add programming-principles skill (14 classic software books) - SKILL.md v0.2.0 with cross-cutting principles, task-to-book mapping, and code-assessment workflow - 29 reference files (14 mini + 14 full + assessment methodology) - Agent-agnostic frontmatter (compatibility field, no Hermes-specific metadata) - Wire neckbeard routing table: code review/refactoring/quality assessment - Regenerate Claude marketplace + Codex plugin manifests (97 skills) Source: magnus919/programming-principles (standalone repo, v0.1.1). Local copy was v0.2.0 with code-assessment-workflow.md not yet upstreamed. Standalone repo will be archived with redirect after merge. * fix: satisfy validator — frontmatter fields, skill README, catalog entry - Strip version/author/source from frontmatter (unsupported fields) - Move source attribution into metadata (string-to-string map) - Add programming-principles/README.md with required headings - Add catalog entry to root README.md (alphabetical position) Validator passes locally: 107 canonical skills.
37 lines
2.5 KiB
Markdown
37 lines
2.5 KiB
Markdown
# OBEY Domain-Driven Design Distilled by Vaughn Vernon
|
|
|
|
## When to use
|
|
|
|
Use as a lightweight introduction to DDD when you need the benefits of strategic and tactical DDD without excessive ceremony or when onboarding a team to DDD concepts quickly.
|
|
|
|
## Primary bias to correct
|
|
|
|
DDD is not all or nothing. Start with strategic design — bounded contexts, ubiquitous language, subdomains — and apply tactical patterns only where the complexity lives.
|
|
|
|
## Decision rules
|
|
|
|
- Start with strategic design before tactical patterns. Name the Bounded Context, establish the Ubiquitous Language, and identify Core, Supporting, and Generic subdomains.
|
|
- A Bounded Context owns its model; no other context shares it. Translate between contexts with explicit mapping.
|
|
- Use Context Mapping to document relationships between contexts: Partnership, Shared Kernel, Customer-Supplier, Conformist, Anticorruption Layer, Open Host Service, Published Language, Separate Ways, Big Ball of Mud.
|
|
- Keep Aggregates small. One Aggregate per transaction. Reference by identity. Design around consistency boundaries, not data relationships.
|
|
- Use Domain Events for integration across aggregates or contexts. Keep them past-tense and meaningful to the business.
|
|
- Apply tactical patterns (Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event) only where the complexity warrants them. Simple CRUD does not need DDD.
|
|
- Use Application Services to coordinate use cases; keep them thin. Domain decisions stay in the domain model.
|
|
- Repositories are for Aggregate persistence; they return domain objects. Do not expose table structures or ORM queries.
|
|
- Value Objects are immutable, self-validating, and compare by value. Replace primitives for meaningful domain concepts.
|
|
- Use Core Domain to focus the richest modeling. Spend less on Generic and Supporting subdomains.
|
|
|
|
## Trigger rules
|
|
|
|
- When a term means different things in different parts of the system, define a Bounded Context boundary.
|
|
- When two contexts exchange data, define the context mapping relationship and translation mechanism.
|
|
- When a transaction spans multiple aggregates, challenge the aggregate boundaries or use eventual consistency.
|
|
- When business logic appears in services or controllers, push it into the domain model.
|
|
|
|
## Final checklist
|
|
|
|
- Bounded Context named and documented?
|
|
- Ubiquitous Language established and used in code?
|
|
- Aggregates small, one per transaction, referenced by identity?
|
|
- Core Domain identified and getting richer modeling?
|