Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add j4flmao/agent-skills --skill domain-driven-designgit clone --depth 1 https://github.com/j4flmao/agent-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/j4flmao/agent-skills/domain-driven-design)<a href="https://agentmods.dev/skills/j4flmao/agent-skills/domain-driven-design"><img src="https://agentmods.dev/badge/skills/j4flmao/agent-skills/domain-driven-design/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/j4flmao/agent-skills/domain-driven-design"><img src="https://agentmods.dev/badge/skills/j4flmao/agent-skills/domain-driven-design.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00137 | $0.01979 |
| Opus 5.5 | $0.00055 | $0.00792 |
| Sonnet 5.5 | $0.00027 | $0.00396 |
| Haiku 4.5 | $0.00014 | $0.00198 |
Grade A, and why
architecture-domain-driven-design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 176 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Domain-Driven Design
Purpose
DDD aligns software structure with the business: a shared language inside explicit boundaries, models that enforce business invariants, and deliberate translation where contexts meet. Use it where domain complexity is the main risk (pricing, underwriting, logistics, billing). For simple CRUD, plain layered code is cheaper.
Agent Protocol
Trigger
"DDD", "bounded context", "aggregate", "aggregate root", "entity vs value object", "domain event", "context map", "anti-corruption layer", "ubiquitous language", "event storming".
Input Context
- Business capabilities and processes; domain experts' vocabulary.
- Current pain: tangled models, inconsistent rules, overloaded terms.
- Team structure (contexts usually map to team ownership).
- Persistence and integration constraints.
Output Artifact
Strategic map (subdomains, contexts, relationships) and/or tactical model (aggregates with invariants, value objects, events, repository interfaces).
Response Format
Subdomains: {core|supporting|generic}: {name}
Contexts: {name} owns {terms}; team {x}
Context map: {upstream} -> {downstream} [{pattern}]
Aggregate: {Root} invariants: {list}; references others by id
Events: {PastTenseName}(fields)
Completion Criteria
- Each term defined per context (no global "User"/"Product" model).
- Every aggregate lists the invariants it protects.
- One aggregate modified per transaction; others updated via events.
- Context relationships named with a context-map pattern.
Strategic Design
Subdomains: core (competitive advantage: invest, custom build), supporting (needed, specific: build simply), generic (commodity: buy/SaaS, e.g. auth, payments).
Bounded context: a boundary within which a model and its language are consistent. "Product" in Catalog (description, images), Inventory (SKU, quantity, location), and Pricing (price lists, discounts) are different models that share an identifier.
Context map patterns
| Pattern | Relationship |
|---|---|
| Partnership | Two teams coordinate releases jointly |
| Shared Kernel | Small shared model owned by both (keep tiny) |
| Customer/Supplier | Downstream needs influence upstream's roadmap |
| Conformist | Downstream adopts upstream model as-is |
| Anti-Corruption Layer (ACL) | Downstream translates upstream model into its own terms |
| Open Host Service + Published Language | Upstream offers a stable, documented API/schema for many consumers |
| Separate Ways | No integration; duplicate where cheaper |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today Changed · +132 lines · +137 tokens per session 6e2c45cef5a4
- 1mo ago First seen · 44 lines · 0 tokens per session scan A e3625938b60d
architecture-domain-driven-design is a skill published in the GitHub repository j4flmao/agent-skills (34 stars, last pushed today), licensed MIT. It adds 137 tokens to every session and 1,979 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ddd-aggregate-modeling
Guides aggregate modeling decisions for DDD services: aggregate root boundaries, child entity vs value object decisions, invariants, snapshot/primitives mapping, specification/criteria usage, and repository contract design. Invoked when the user asks to model or refactor domain entities and aggregate behavior.
domain-driven-design
Design and review software using patterns from Eric Evans' "Domain-Driven Design." Use for DDD tactical patterns (Entities, Value Objects, Aggregates, Repositories, Factories, Domain Services), strategic patterns (Bounded Context, Context Map, Anticorruption Layer, Shared Kernel, Open Host Service), supple design…
domain-modeling
DDD practical guide: Event Storming, Bounded Contexts, Aggregates and domain-driven design patterns.
ddd
A guide to domain-driven design, a way of structuring software around the important concepts and rules of a business. It covers business boundaries, domain models, and common building blocks such as entities and value objects.
architecture-paradigm-domain-driven
Models a business in its own language. Use when the domain has real business rules to capture.
architecture-patterns
Software architecture patterns and best practices.