architecture-ddd

Sterne7

Forks0

Aktualisiert17. Februar 2026 um 08:24

Domain-driven design workflow for bounded context partitioning, aggregate design, and context mapping in complex domains. Use when domain complexity or organizational scaling requires explicit model boundaries; do not use for small CRUD domains without competing language models.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

KentoShimizu

KentoShimizu/sw-agent-skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	architecture-ddd
description	Domain-driven design workflow for bounded context partitioning, aggregate design, and context mapping in complex domains. Use when domain complexity or organizational scaling requires explicit model boundaries; do not use for small CRUD domains without competing language models.

Architecture DDD

Overview

Use this skill to model complex domains so teams can evolve behavior without constant cross-team coupling.

Scope Boundaries

Domain language differs across teams or subsystems.
Invariants are hard to maintain because boundaries are unclear.
A single model is causing conflicting meanings and high coordination cost.

Core Judgments

Bounded context cuts: where language and invariants legitimately diverge.
Aggregate boundaries: where consistency must be immediate versus eventual.
Context integration style: ACL, conformist, published language, or shared kernel.
Ownership model: which team can change which part without global coordination.

Practitioner Heuristics

Bound contexts by change patterns and invariants, not by database tables.
Aggregates should protect invariants with minimal transactional scope.
Cross-context communication should exchange explicit contracts, not internal models.
In dynamic languages, model entities/value objects with explicit typed schemas instead of broad maps that require repetitive casting.

Workflow

Build ubiquitous language per domain area and identify conflicting terms.
Partition bounded contexts by invariants, autonomy, and change cadence.
Design aggregates with clear consistency and lifecycle rules.
Define context map and integration contracts between contexts.
Identify anti-corruption needs and translation responsibilities.
Document residual ambiguity and model evolution triggers.

Common Failure Modes

"DDD" applied as folder naming without boundary behavior changes.
Aggregates oversized, causing lock contention and slow writes.
Shared database schema used as de facto integration API.

Failure Conditions

Stop when bounded contexts cannot be separated by language/invariant boundaries.
Stop when aggregate consistency needs conflict with transaction feasibility.
Escalate when cross-context contracts remain uncontrolled.

Mehr aus diesem Repository

gleiches Repository

debug-root-cause

KentoShimizu/sw-agent-skills

Systematic debugging workflow for isolating software root causes, implementing proportional fixes, and verifying recovery with reproducible evidence. Use when application/runtime failures, regressions, or flaky behavior are observed and the task requires both diagnosis and remediation. When specialized skills are available in the environment, defer GitHub Actions failure triage to `github-fix-ci`, commit-introduction isolation to `git-bisect-debugging`, profiler-led hotspot analysis to `performance-profiling`, active security incident command to `security-incident-response`, and postmortem-only reporting to `incident-postmortem`. Do not use for broad feature implementation or speculative hardening without evidence.

2026-03-027

api-design-rest

KentoShimizu/sw-agent-skills

Resource-oriented REST/OpenAPI contract design for URI/method semantics, idempotency, pagination, and HTTP status behavior. Trigger when REST contract diffs are detected in paths, methods, schemas, or status semantics, or when request-response transport choice is still unresolved before implementation. Do not use for GraphQL schema authoring, error-taxonomy-only changes, version lifecycle governance, or consumer-provider contract test implementation.

2026-02-177

ab-testing

KentoShimizu/sw-agent-skills

Controlled online experiment workflow for product changes with causal inference, randomization integrity checks, and pre-registered decision criteria. Trigger when ship/no-ship decisions require causal evidence under uncertainty and KPI trade-offs must be quantified. Do not use for feature-flag rollout policy without experiment design, deterministic functional verification, or observability-only analysis.

2026-02-177

testing-contract

KentoShimizu/sw-agent-skills

Provider-consumer compatibility testing for service interface changes. Use when APIs or event schemas evolve and executable contract checks must guard compatibility before release; do not use for UI-only validation or architecture topology decisions.

2026-02-177

testing-e2e

KentoShimizu/sw-agent-skills

End-to-end test planning for critical user journeys across integrated systems. Use when release confidence depends on browser/API/dependency behavior as one flow; do not use for isolated unit behavior or pure contract checks.

2026-02-177

testing-regression-strategy

KentoShimizu/sw-agent-skills

Risk-based regression suite curation for release gating under time and budget limits. Use when teams must decide what runs always versus conditionally by impact and risk; do not use for implementing a single test type in isolation.

2026-02-177

name	architecture-ddd
description	Domain-driven design workflow for bounded context partitioning, aggregate design, and context mapping in complex domains. Use when domain complexity or organizational scaling requires explicit model boundaries; do not use for small CRUD domains without competing language models.

Architecture DDD

Overview

Use this skill to model complex domains so teams can evolve behavior without constant cross-team coupling.

Scope Boundaries

Domain language differs across teams or subsystems.
Invariants are hard to maintain because boundaries are unclear.
A single model is causing conflicting meanings and high coordination cost.

Core Judgments

Bounded context cuts: where language and invariants legitimately diverge.
Aggregate boundaries: where consistency must be immediate versus eventual.
Context integration style: ACL, conformist, published language, or shared kernel.
Ownership model: which team can change which part without global coordination.

Practitioner Heuristics

Bound contexts by change patterns and invariants, not by database tables.
Aggregates should protect invariants with minimal transactional scope.
Cross-context communication should exchange explicit contracts, not internal models.
In dynamic languages, model entities/value objects with explicit typed schemas instead of broad maps that require repetitive casting.

Workflow

Build ubiquitous language per domain area and identify conflicting terms.
Partition bounded contexts by invariants, autonomy, and change cadence.
Design aggregates with clear consistency and lifecycle rules.
Define context map and integration contracts between contexts.
Identify anti-corruption needs and translation responsibilities.
Document residual ambiguity and model evolution triggers.

Common Failure Modes

"DDD" applied as folder naming without boundary behavior changes.
Aggregates oversized, causing lock contention and slow writes.
Shared database schema used as de facto integration API.

Failure Conditions

Stop when bounded contexts cannot be separated by language/invariant boundaries.
Stop when aggregate consistency needs conflict with transaction feasibility.
Escalate when cross-context contracts remain uncontrolled.