barcelosvinicius Skill: Domain Mapping Pipeline
What this skill is
Defines the repeatable process for deriving a DDD-aligned domain model from an existing or new codebase. The pipeline works whether the project already uses DDD terminology or not — it extracts business intent from naming conventions, data flows, and module boundaries.
The output is a domain map that answers: "What business problems does this code solve, in what order, and where exactly do those responsibilities live?"
When to run
| Trigger | Recommended action |
|---|---|
| Project kickoff | Full pipeline — establish the baseline domain map |
| New bounded context | Phases 1–3 for the new context only |
| Suspected boundary drift | Phase 2 + Phase 4 on affected modules |
| Pre-release architecture review | Phase 4 (validation only) |
| Onboarding new AI agent | Provide the domain map as context |
Core DDD vocabulary used in this skill
Glossary in output-schemas.md — bounded context, aggregate, domain event, and the rest, with the meaning this skill assumes.
Pipeline phases
Phase 1 — Context discovery
↓ identify bounded contexts from module structure
Phase 2 — Model extraction
↓ find aggregates, entities, value objects, events per context
Phase 3 — Flow mapping
↓ trace process flows end-to-end across contexts
Phase 4 — Boundary validation
↓ verify context isolation; flag leakage and missing anti-corruption layers
Phase 5 — Output assembly
↓ produce domain-map section for structural-analysis.md
Phase 1 — Context discovery
Goal: name the bounded contexts and assign every module to one.
Discovery heuristics
Look for naming signals in package/module names, directory names, and class names:
| Signal | Likely bounded context |
|---|---|
billing, payment, invoice, subscription |
Billing |
auth, identity, user, account, session |
Identity |
catalog, product, inventory, sku |
Catalogue |
order, checkout, cart, fulfillment |
Order |
notification, email, sms, push |
Notification |
report, analytics, metric, dashboard |
Analytics |
Output per context
Schema in output-schemas.md.
Phase 2 — Model extraction
Goal: identify the building blocks inside each bounded context.
For each context, extract:
Aggregates and entities
| What to look for | How to recognise it |
|---|---|
| Aggregate root | Class with identity field (id, uuid), annotated @Entity or equivalent |
| Value object | Immutable class, no id, equality by value |
| Repository | Interface/class named *Repository, *DAO, *Store |
| Domain service | Class named *Service in the domain layer (not in application or api) |
| Application service | Class in application or usecase package, orchestrates domain objects |
Domain events
Look for:
- Classes named
*Event,*Created,*Updated,*Cancelled - Publisher/dispatcher calls (Spring
ApplicationEvent, Kafka producer, etc.) - Listener/consumer registrations
Record:
event:
name: [e.g., OrderPlaced]
publisher: [module that emits it]
consumers: [modules that react to it]
payload: [key fields]
Phase 3 — Flow mapping
Goal: trace process flows end-to-end through the system.
For each significant user journey or business process:
flow:
name: [e.g., "Place order", "Reset password", "Generate monthly invoice"]
trigger: [HTTP request, cron job, domain event, user action]
steps:
1. [Layer: api] [file/class] — [what it does]
2. [Layer: service] [file/class] — [what it does]
3. [Layer: domain] [file/class] — [what it does]
4. [Layer: data] [file/class] — [what it does]
output: [what the flow produces — response, event, record]
external_calls: [third-party services invoked]
failure_paths: [what happens if each step fails]
Flow completeness checklist
- Every RF (functional requirement) maps to at least one flow
- Every flow has an explicit trigger
- Every flow has identified failure paths
- External calls are documented (SLA, retry policy)
Phase 4 — Boundary validation
Goal: verify that bounded contexts are properly isolated.
Context coupling anti-patterns
| Anti-pattern | Description | Severity |
|---|---|---|
| Shared entity | Same JPA entity used in two contexts | 🔴 Critical |
| Direct service call | Context A calls Context B's service directly | 🟠 High |
| Shared database table | Two contexts read/write the same table | 🔴 Critical |
| Missing anti-corruption layer | External system's model leaks into domain | 🟡 Medium |
| Implicit context | Logic spread across unowned modules | 🟡 Medium |
Anti-corruption layer (ACL) checklist
An ACL is required whenever:
- A bounded context integrates with a third-party API
- Two bounded contexts need to share data (translate, do not reference directly)
- A legacy module is being strangled by a new context
Record each missing ACL as a pending item in structural-analysis.md.
Phase 5 — Output assembly
This skill owns the ## Domain map section of structural-analysis.md. Its
schema — bounded contexts, context relationships, the domain event catalogue and
the flow index — is defined once, in
output-schemas.md, and nowhere else.
Integration with other skills
| Skill | How domain mapping feeds it |
|---|---|
proc-structural-analysis |
Phase 4 (domain extraction) of that pipeline uses this skill's output |
proc-impact-analysis |
Domain map enables precise impact scoping — change in Context A does not automatically affect Context B |
proc-sdd |
Specs reference bounded contexts; each context is a candidate for its own spec |
| Agent definitions | Each agent should declare which bounded context(s) it owns |
Size verdict
Q1 — does the trigger split? No: kickoff, a new bounded context and drifted
boundaries all produce one artefact, the domain map. Q2 — what is lookup?
The DDD glossary and the output schemas, now in output-schemas.md. What
remains is the five-phase procedure. Verdict: leave it.
Resources
- output-schemas.md — the
## Domain mapsection schema (defined here and nowhere else), the DDD glossary, and the per-context output.
See also: the proc-structural-analysis, proc-impact-analysis, and proc-sdd skills.