Ddd Guidance
@webframp/ddd-guidancev2026.08.21.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.
02Release Notes
2026.08.21.1
Changed: Added .describe(...) documentation to previously undocumented
fields in the resource-only schemas ContextMapSchema, DomainGlossarySchema,
and BoundariesSchema (and their nested ContextRelationshipSchema,
BoundedContextSchema, GlossaryEntrySchema, InvariantSchema, and
AggregateDesignSchema). The corresponding method argument schemas already
had descriptions; this brings the resource schemas up to the same standard.
No behavioral changes.
2026.07.18.1
Added: An upgrades array entry (no-op) to mod.ts for proper typeVersion tracking on existing instances. No schema or behavior changes.
03Models
@webframp/ddd-guidancev2026.07.18.1ddd-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, contexts: array, relationships: array, overloadedTerms: array)
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 |
| contexts | array | Bounded contexts discovered through conversation |
| relationships | array | Relationships between bounded contexts |
| overloadedTerms | array | Terms that mean different things in different contexts |
fn language(mode: enum, context: string, entries: array, overloadedTerms?: array)
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 |
|---|---|---|
| mode | enum | Write strategy: merge (default), replace-context, or replace-all |
| context | string | Bounded context name these terms belong to |
| entries | array | Glossary entries captured through conversation |
| overloadedTerms? | array | Any newly discovered terms that are overloaded across contexts |
fn boundaries(context: string, aggregates: array, eventualConsistencyRules: array)
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
Present the glossary entries for this context and ask: "Which of these
terms cluster
| Argument | Type | Description |
|---|---|---|
| context | string | Bounded context name these boundaries belong to |
| aggregates | array | Aggregate designs produced through Vernon's rules analysis |
| eventualConsistencyRules | array | Cross-aggregate consistency rules that tolerate eventual consistency |
fn revisit()
Review existing DDD decisions against recent system changes.
Domain understanding evolves. 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 state and its discoveredAt/updatedAt timestamps.
Ask: "What has changed since these were last update
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
04Previous Versions
2026.07.18.1
2026.07.18.1
Added: An upgrades array entry (no-op) to mod.ts for proper typeVersion tracking on existing instances. No schema or behavior changes.
2026.06.25.3
2026.06.25.1
2026.06.23.1
2026.06.15.1
2026.06.05.2
05Stats
A
100 / 100
Downloads
20
Archive size
22.7 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
06Platforms
07Labels