Ddd Guidance
@webframp/ddd-guidancev2026.06.15.1
01README
Guides teams through applying Domain-Driven Design to existing projects. Structured discovery of bounded contexts, ubiquitous language capture, and aggregate boundary design using Vernon's rules of thumb.
Stores typed, versioned domain knowledge that agents can query to inform architectural decisions over time.
02Models
@webframp/ddd-guidancev2026.06.05.2ddd-guidance/mod.ts
Global Arguments
| Argument | Type | Description |
|---|---|---|
| projectContext | string | Brief description of the project, its domain, and team structure |
| existingPatterns | array | Architectural patterns already in use (e.g., microservices, monolith, event-driven) |
fn contexts(focus?: string)
Discover bounded contexts through structured conversation.
Guide the discussion through these phases:
1. TERM INVENTORY
Ask: "What are the core terms in your domain? List the nouns your team
uses daily — things like 'order', 'customer', 'deployment', 'incident'."
For each term, ask: "Does this word mean the same thing to everyone
on every team?" Record where terms are overloaded.
2. OWNERSHIP BOUNDARIES
Ask: "Who owns what? Which teams or people are responsible for
which par
| Argument | Type | Description |
|---|---|---|
| focus? | string | Optional: narrow discovery to a specific area of the system |
fn language(context?: string)
Capture ubiquitous language for a bounded context.
Guide the conversation through these phases:
1. CONTEXT SELECTION
Read the contextMap resource. Present the discovered bounded contexts.
Ask: "Which context should we define language for?" If a 'context'
argument is provided, use that directly.
2. TERM ELICITATION
For the selected context, ask: "What are the essential nouns, verbs,
and adjectives in this context? Think of the terms a new team member
would need to learn befor
| Argument | Type | Description |
|---|---|---|
| context? | string | Bounded context name to capture language for (uses first context if omitted) |
fn boundaries(context?: string)
Identify aggregate boundaries within a bounded context.
Guide the conversation through these phases using Vernon's Aggregate
Rules of Thumb:
1. CONTEXT SELECTION
Read the contextMap and domainGlossary resources. Present context and
its terms. Ask: "Which context should we design aggregate boundaries
for?" If a 'context' argument is provided, use that directly.
2. AGGREGATE CANDIDATE CLUSTERING
Before applying Vernon's rules, help the team translate glossary terms
into candidate
| Argument | Type | Description |
|---|---|---|
| context? | string | Bounded context name to design boundaries for |
fn revisit()
Review existing DDD decisions against recent system changes.
Domain understanding evolves. New services appear, teams reorganize, incidents
reveal hidden coupling, and business priorities shift. This method guides a
structured review of prior context, language, and boundary decisions to
determine what still holds and what needs updating.
Guide the conversation through these phases:
1. CHANGE INVENTORY
Read all three resources (contextMap, domainGlossary, boundaries).
Present the current
Resources
contextMap(infinite)— Discovered bounded contexts, their relationships, and overloaded terms
domainGlossary(infinite)— Per-context term glossary capturing ubiquitous language definitions
boundaries(infinite)— Aggregate designs with invariants, identity references, and consistency rules
03Previous Versions
2026.06.05.2Jun 5, 2026
04Stats
A
100 / 100
Downloads
1
Archive size
21.3 KB
- Has README or module doc2/2earned
- README has a code example1/1earned
- README is substantive1/1earned
- Most symbols documented1/1earned
- No slow types (deprecated)1/1earned
- Dependencies pass trust audit2/2earned
- Has description1/1earned
- Platform support declared (or universal)2/2earned
- License declared1/1earned
- Verified public repository2/2earned
05Platforms
06Labels