When should I use Domain-Driven Design?

Use this skill when you need to model a complex business domain with explicit boundaries, decide whether full DDD is justified, or plan advanced patterns like CQRS, event sourcing, sagas, or projections. The skill recommends full DDD only when at least two of these conditions are true: business rules are complex or fast-changing, multiple teams are causing model collisions, integration contracts are unstable, or auditability and explicit invariants are critical.

What does the Domain-Driven Design skill produce?

The skill produces strategic artifacts like subdomains, bounded contexts, and language glossaries, along with scope and assumptions, current stage identification (strategic, tactical, or evented), explicit artifacts, open risks, and next step recommendations.

What specialized skills does Domain-Driven Design route to?

The skill routes to specialized sub-skills including @ddd-strategic-design for boundaries, @ddd-context-mapping for cross-context integrations, @ddd-tactical-patterns for code modeling, @cqrs-implementation for read/write separation, @event-sourcing-architect and @event-store-design for event history, @saga-orchestration for workflows, @projection-patterns for read models, and @architecture-decision-records for decision logging.

When should I NOT use Domain-Driven Design?

Do not use this skill for simple CRUD systems with low business complexity, when you only need localized bug fixes, or when there is no access to domain knowledge and no proxy product expert. It should not be used to over-engineer simple systems.

Skill

Assess and Apply Domain-Driven Design

Name: Domain-Driven Design
Availability: OnlineOnly
Author: Antigravity

A DDD entry-point skill that runs a viability check, then routes to strategic, tactical, or event-sourcing sub-skills.

Get skill

Antigravity

Own this? Claim it

Spark score

out of 100

Updated last month

Version 13.1.0

Add to Favorites

Why it matters

Determine if Domain-Driven Design (DDD) is suitable for your complex business domain. This skill helps you model explicit boundaries and connect strategic decisions to implementation patterns.

Outcomes

What it gets done

Perform a DDD viability check based on business complexity and team dynamics.

Generate strategic artifacts like subdomains, bounded contexts, and glossaries.

Route to specialized skills for tactical patterns, event sourcing, or CQRS.

Define success criteria and identify open risks for DDD adoption.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-domain-driven-design | bash

Overview

Domain-Driven Design

A DDD entry-point skill that runs a viability check, produces strategic artifacts, and routes to specialized context-mapping, tactical, CQRS, or event-sourcing skills. Use it to decide whether a domain warrants full DDD and which specialized skill to apply next, not for simple CRUD or localized bug fixes.

What it does

Domain-Driven Design is an entry-point skill that first runs a viability check before committing to full DDD, then produces strategic artifacts (subdomains, bounded contexts, a language glossary) and routes the task to a specialized skill. Full DDD is recommended only when at least two of four signals hold: business rules are complex or fast-changing, multiple teams are causing model collisions, integration contracts are unstable, or auditability and explicit invariants are critical. The routing map covers strategic model and boundaries (@ddd-strategic-design), cross-context integration (@ddd-context-mapping), tactical code modeling (@ddd-tactical-patterns), read/write separation (@cqrs-implementation), event-sourcing (@event-sourcing-architect, @event-store-design), long-running workflows (@saga-orchestration), read models (@projection-patterns), and decision logs (@architecture-decision-records). A representative invocation:

Use @domain-driven-design to assess if this billing platform should adopt full DDD.
Then route to the right next skill and list artifacts we must produce this week.

When to use - and when NOT to

Use this skill when modeling a complex business domain with explicit boundaries, deciding whether full DDD is worth the added complexity, connecting strategic design decisions to implementation patterns, or planning CQRS, event sourcing, sagas, or projections from domain needs. Don't use it for simple CRUD with low business complexity, for localized bug fixes, or when there's no access to domain knowledge or a proxy product expert. It explicitly does not replace direct workshops with domain experts, does not provide framework-specific code generation, and should not be used to justify over-engineering a simple system. Templates are available in a companion references/ddd-deliverables.md file.

Inputs and outputs

Input is a business domain and its current complexity signals; output always includes scope and assumptions, the current stage (strategic, tactical, or evented), explicit artifacts produced, and open risks with a next-step recommendation - plus a routing decision to the appropriate specialized DDD skill.

Who it's for

Architects and teams deciding whether a domain warrants full DDD and, if so, which specialized DDD skill to apply next - strategic design, context mapping, tactical patterns, CQRS, event sourcing, or sagas - rather than picking a DDD pattern without first checking it's justified.

FAQ

Common questions

Discussion