無料GitHub で公開

ddd

Domain-Driven Design system for software development. Use when designing new systems with DDD principles, refactoring existing codebases toward DDD, generating code scaffolding (entities, aggregates, repositories, domain events), facilitating Event Storming sessions, creating bounded context maps, or performing code reviews with a DDD lens. Covers both strategic design (bounded contexts, subdomains, context maps, ubiquitous language) and tactical design (entities, value objects, aggregates, domain services, repositories). Supports all major architecture patterns (Hexagonal/Ports & Adapters, CQRS, Event Sourcing, Clean Architecture) with language-agnostic guidance and concrete examples in Python and TypeScript.

svngoku/coding-agents-skills

インストール方法を見る

含まれるファイル（13）

SKILL.md6.2 KB
eval.yaml1.2 KB
graders/check.py14.5 KB
instructions/checkout-domain-model.md3.4 KB
references/architecture-patterns.md21.0 KB
references/code-review.md9.6 KB
references/event-storming.md13.2 KB
references/python-patterns.md19.6 KB
references/strategic-design.md7.9 KB
references/tactical-design.md11.3 KB
references/typescript-patterns.md23.1 KB
rubrics/quality.md3.0 KB
solutions/reference-checkout-domain7.1 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Domain-Driven Design Skill

Apply DDD to build software that reflects deep understanding of the business domain.

Quick Reference

Task	Reference
Bounded contexts, subdomains, context maps	strategic-design.md
Entities, value objects, aggregates, repositories	tactical-design.md
Hexagonal, CQRS, Event Sourcing, Clean Architecture	architecture-patterns.md
Event Storming facilitation & documentation	event-storming.md
Python implementations (Pydantic, SQLAlchemy, FastAPI)	python-patterns.md
TypeScript implementations (NestJS, TypeORM, Prisma)	typescript-patterns.md
DDD code review criteria	code-review.md

Core Workflow

1. Identify the Task Type

Designing new system? → Start with strategic design, then tactical Refactoring existing code? → Assess current state, identify bounded contexts, refactor incrementally Generating scaffolding? → Determine patterns needed, generate code Event Storming? → Follow facilitation guide Code review? → Apply DDD checklist

2. Strategic Before Tactical

Always establish strategic design first:

Identify subdomains (Core, Supporting, Generic)
Define bounded contexts and their boundaries
Map context relationships (upstream/downstream, conformist, ACL, etc.)
Establish ubiquitous language per context

3. Select Architecture Pattern

Choose based on domain complexity and requirements:

Pattern	When to Use
Layered	Simple CRUD, low complexity
Hexagonal	Need to isolate domain from infrastructure
Clean Architecture	Complex business rules, multiple delivery mechanisms
CQRS	Different read/write models, complex queries
Event Sourcing	Audit trail required, temporal queries, event-driven

Patterns can be combined (e.g., Hexagonal + CQRS + Event Sourcing).

4. Apply Tactical Patterns

Select tactical building blocks based on needs:

Building Block	Purpose
Entity	Identity matters, mutable, lifecycle
Value Object	Defined by attributes, immutable, no identity
Aggregate	Consistency boundary, transactional unit
Domain Service	Stateless operations spanning multiple aggregates
Repository	Collection-like interface for aggregate persistence
Domain Event	Record of something significant that happened
Factory	Complex object creation logic
Specification	Encapsulated business rules for querying/validation

5. Implementation Guidelines

General principles:

Domain layer has ZERO infrastructure dependencies
Depend on abstractions (interfaces/protocols), not concretions
One aggregate = one repository = one transaction
Aggregates reference other aggregates by ID only
Validate invariants within aggregate boundaries
Use domain events for cross-aggregate communication

Language selection:

Read python-patterns.md for Python with Pydantic, SQLAlchemy, FastAPI
Read typescript-patterns.md for TypeScript with NestJS, TypeORM, Prisma

Project Structure Template

src/
├── domain/                    # Pure domain logic (no dependencies)
│   ├── model/                 # Entities, Value Objects, Aggregates
│   ├── service/               # Domain Services
│   ├── event/                 # Domain Events
│   ├── repository/            # Repository interfaces (ports)
│   └── specification/         # Business rule specifications
├── application/               # Use cases, orchestration
│   ├── command/               # Command handlers (write)
│   ├── query/                 # Query handlers (read)
│   ├── dto/                   # Data transfer objects
│   └── service/               # Application services
├── infrastructure/            # External concerns
│   ├── persistence/           # Repository implementations
│   ├── messaging/             # Event bus, message queue
│   └── external/              # Third-party integrations
└── interface/                 # Delivery mechanisms
    ├── api/                   # REST/GraphQL controllers
    ├── cli/                   # Command-line interface
    └── event/                 # Event consumers

Anti-Patterns to Avoid

Anemic Domain Model: Entities with only getters/setters, logic in services
God Aggregate: Too many entities in one aggregate
Shared Kernel Abuse: Overusing shared code between contexts
Infrastructure Leak: Database concerns in domain layer
Missing Ubiquitous Language: Technical terms instead of domain terms
Aggregate Reference by Object: Should reference by ID only
Transaction Across Aggregates: Violates consistency boundaries

When NOT to Use DDD

DDD adds complexity. Avoid for:

Simple CRUD applications
Technical/infrastructure projects without complex business logic
Prototypes or throwaway code
Teams unfamiliar with the domain (learn domain first)

Use DDD when:

Complex, evolving business logic
Long-lived systems requiring maintainability
Multiple teams working on related domains
Domain experts available for collaboration

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

adaption-ai

無料

Adaption AI SDK for synthetic data augmentation and dataset adaptation. Use when building data pipelines with the Adaption Python SDK, uploading datasets (local files, Hugging Face, Kaggle), running augmentation/adaptation jobs, configuring brand controls (hallucination mitigation, safety categories, length), recipe specifications (reasoning traces, deduplication, preference pairs, prompt rephrase), evaluating dataset quality, downloading results, or any workflow involving `pip install adaption`, `from adaption import Adaption`, Adaptive Data, or the adaptionlabs.ai API. Also trigger when the user mentions synthetic data generation for fine-tuning, dataset augmentation pipelines, DPO preference pair generation, or grounding-based hallucination reduction on training data.

日本語の概要は準備中です。原文の説明を表示しています。