ts-ddd-bounded-context

name

ts-ddd-bounded-context

description

Map bounded contexts for a TypeScript DDD project — identify context boundaries, define ubiquitous language, map relationships (ACL, Partnership, Shared Kernel, etc.), and surface aggregate roots and domain events. Trigger when the user says "map the domain", "define bounded contexts", "what are the aggregates", "design the domain model", "identify the ubiquitous language", "how should we split this domain", or when planning a new feature that touches multiple domain areas. Also trigger when the user describes a business process and wants to know how to structure it in DDD.

Bounded Context Mapper — TypeScript DDD

Produce a structured domain map that gives the team a shared understanding of where responsibilities live, how contexts relate, and what language each context owns.

Process (follow in order)

1. Extract domain concepts

From the user's description, identify and list:

• Nouns → candidate Entities and Value Objects
• Verbs → candidate Domain Events and Commands
• Business rules → candidate invariants for Aggregates

2. Group into bounded contexts

Cluster concepts that share a ubiquitous language and a clear owner. Each bounded context should:

• Have a single team or module owning it
• Have a name that domain experts recognize
• Be cohesive — the language inside it doesn't leak to other contexts

3. Define relationships

For each pair of interacting contexts, name the relationship pattern:

Pattern	When to use
Shared Kernel	Two contexts share a small, stable subset of the model
Customer/Supplier	One context consumes another's output; upstream is the supplier
Conformist	Downstream adapts entirely to upstream's model
Anti-Corruption Layer (ACL)	Downstream translates upstream's model to protect its own language
Open Host Service	Upstream publishes a stable, versioned API for many consumers
Published Language	Shared data format (e.g. events on a bus) both sides agree on
Partnership	Two contexts evolve together with joint planning
Separate Ways	No integration — contexts are fully independent

4. Identify aggregates per context

For each context, name:

• The Aggregate Root (the entity that owns the transaction boundary)
• Its children (entities and value objects inside the boundary)
• The domain events it emits

5. Define ubiquitous language

For each context, list the key terms with one-line definitions. If the same word means different things in different contexts (e.g. "Order" in Billing vs. Shipping), call it out explicitly — this is a linguistic boundary.

---

Output format

# Domain Map: [System / Feature Name]

## Bounded Contexts

### [ContextName]
**Responsibility:** [one sentence]
**Owner:** [team or module name]
**Aggregate Roots:**
- `[AggregateName]` — [one-line responsibility]
  - Children: `[Entity]`, `[ValueObject]`
  - Emits: `[DomainEventName]`, ...

**Ubiquitous Language:**
| Term | Definition |
|------|-----------|
| [Term] | [Definition as understood inside this context only] |

---

### [AnotherContextName]
...

---

## Context Map

```
[ContextA] --[ACL]--> [ContextB]
[ContextB] --[Customer/Supplier]--> [ContextC]
[ContextA] --[Shared Kernel]--> [ContextD]
```

### Relationship details
- **[ContextA] → [ContextB]** (ACL): [ContextB] translates [ContextA]'s `Order` into its own `Purchase` to avoid coupling.
- **[ContextB] → [ContextC]** (Customer/Supplier): [ContextB] publishes `OrderShippedEvent`; [ContextC] subscribes.

---

## Linguistic boundaries

List any terms that appear in multiple contexts with *different meanings*. These are red flags for accidental coupling.

| Term | [ContextA] meaning | [ContextB] meaning |
|------|-------------------|-------------------|
| Order | Customer's purchase intent | Warehouse pick-list |

---

## Domain events flow

```
[AggregateA] --emits--> [DomainEventX] --consumed by--> [ContextB handler]
```

---

## Open questions

- [ ] [Unresolved design decision or missing domain knowledge]

---

TypeScript folder structure (suggest this after mapping)

src/
  [context-name]/               ← one folder per bounded context
    domain/
      [AggregateName].ts        ← aggregate root
      [ValueObject].ts
      events/
        [DomainEventName].ts
      repositories/
        I[AggregateName]Repository.ts   ← interface only
    application/
      use-cases/
        [ActionName]UseCase.ts
      dtos/
    infrastructure/
      persistence/
        [AggregateName]Repository.ts   ← implementation

---

Quality checks

Before finishing the map, verify:

• Every aggregate root has at least one domain event
• No entity is shared between two contexts without a Shared Kernel or ACL
• Every relationship has a named pattern
• Linguistic boundaries are documented
• The map answers: "who owns the data?" for every core entity