domain-driven-design

domain-driven-design is a skill for Claude Code, Codex from booklib-ai/booklib. It costs 191 tokens per session (2,008 once invoked), scanned A, original, MIT.

A software-design guide based on Eric Evans’ Domain-Driven Design, a way to model software around the business concepts and rules it represents.

In plain words
What is it for?
Use it to design or review entities, value objects, aggregates, repositories, services, bounded contexts, and other domain models.
Why use it?
It helps teams choose structures that keep business rules understandable as an application grows.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/booklib-ai/booklib/domain-driven-design
Any agent
npx skills add booklib-ai/booklib --skill domain-driven-design
Clone the repo
git clone --depth 1 https://github.com/booklib-ai/booklib

Made for: Claude Code, Codex.

Wrote 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.

agentmods badge for domain-driven-design

README.md
[![agentmods](https://agentmods.dev/badge/skills/booklib-ai/booklib/domain-driven-design.svg)](https://agentmods.dev/skills/booklib-ai/booklib/domain-driven-design)
Your own site
<a href="https://agentmods.dev/skills/booklib-ai/booklib/domain-driven-design"><img src="https://agentmods.dev/badge/skills/booklib-ai/booklib/domain-driven-design.svg" alt="Measured on agentmods" height="20"></a>
Per session 191 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,008 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00191 $0.02008
Opus 5 $0.00096 $0.01004
Sonnet 5 $0.00038 $0.00402
Haiku 4.5 $0.00019 $0.00201

Measured 5d ago against content hash 428dd54d03b2, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

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 5d ago.

The scan reads SKILL.md. This mod also ships 2 executable files (scripts/example.py, scripts/scaffold.py), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

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.

skills/domain-driven-design/SKILL.md · 143 lines

How it starts

The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Domain-Driven Design Skill

You are an expert software architect grounded in Eric Evans' Domain-Driven Design. You help developers in three modes: Code Generation, Code Review, and Domain Migration Planning.

  • Generate/build/create/model/design → Code Generation
  • Review/check/improve/audit/critique/refactor → Code Review
  • Migrate to DDD/enrich domain/refactor toward DDD → Migration Planning

Mode 1: Code Generation

Pattern Selection

Problem Pattern
Application structure Layered Architecture: UI → Application → Domain → Infrastructure
Object with identity and lifecycle Entity (identity-based equality)
Descriptive concept without identity Value Object (immutable, attribute-based equality, side-effect-free)
Enforce invariants across related objects Aggregate (root entity, single boundary, transactional consistency)
Complex object creation Factory (enforces all invariants atomically)
Collection-like persistence access Repository (only for Aggregate roots)
Operation belonging to no single object Domain Service (stateless, Ubiquitous Language name)
Composable business rules Specification (isSatisfiedBy, and/or/not combinators)
Integration with external system Anticorruption Layer (Façade + Adapter + Translator)
Shared model between teams Shared Kernel (explicit joint ownership)
API for many consumers Open Host Service + Published Language
Core competitive advantage Core Domain distillation, Segregated Core

Code Generation Principles

  • Ubiquitous Language — Class/method/variable names reflect domain terms. No "Manager", "Helper", "Processor" in the domain layer.
  • Layered Architecture — Domain layer has zero dependencies on infrastructure. Infrastructure implements domain interfaces.
  • Entities — Identity-based equality. Focused on lifecycle behavior, not data bags.
  • Value Objects — Immutable. Attribute-based equality. Rich behavior (operations return new instances). Prefer over Entities when identity doesn't matter. Use for all domain concepts expressed as primitives: Money, OrderId, Email, Address, Dimensions.
  • Aggregates — Single root entity. All external access through root. Enforce invariants at boundaries. Keep small; reference other Aggregates by ID only.
  • Repositories — Collection-like interface. Domain layer defines the interface; infrastructure implements it. Only one Repository per Aggregate root.
  • Factories — Encapsulate complex creation. Use private constructors + static factory methods to enforce invariants at creation time.
  • Domain Services — Stateless. Named in Ubiquitous Language. Only for operations that genuinely don't belong on any Entity or Value Object.
  • Specification — Business rules that combine, reuse, or query use isSatisfiedBy() with boolean combinators.
  • Anticorruption Layer — Translate external models to your domain model. Domain interfaces know nothing about the external system.

Read the full file on GitHub · 143 lines

Files

What ships with it

10 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

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.

  1. 5d ago First seen · 143 lines · 191 tokens per session scan A 428dd54d03b2

Subscribe to this mod's changes

domain-driven-design is a skill published in the GitHub repository booklib-ai/booklib (38 stars, last pushed 4mo ago), licensed MIT. It adds 191 tokens to every session and 2,008 once invoked, about $0.0010 per session on Opus 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.

Related

Other skills, from other repositories

project-spine-kickoff

Use when the user wants to set up Project Spine for a new project — phrases like "new client project", "kickoff", "create AGENTS.md from scratch", "generate agent instructions for this repo", "set up project context". Runs spine init → edits brief → spine compile → reviews outputs. For stale files use…

PetriLahdelma/project-spine · 84 tokens

project-spine

Use when the user mentions AGENTS.md, CLAUDE.md, copilot-instructions, Cursor rules, project brief, context for coding agents, agency kickoff, onboarding a new project, or asks "how do I set up Project Spine". This is the orientation skill — reach for it FIRST when the user's intent involves Project Spine, then chain…

PetriLahdelma/project-spine · 80 tokens

project-spine-drift

Use when the user mentions drift, says AGENTS.md / CLAUDE.md / copilot-instructions / Cursor rules are "stale" or "out of date", asks about CI catching docs drift, or says "check if my spine is still current". Runs spine drift check, interprets each drift category, and guides resolution. For initial setup use…

PetriLahdelma/project-spine · 87 tokens

project-spine-rationale

Use when the user wants to review, polish, or share the generated Project Spine rationale file locally. Phrases like "show the project rationale", "send the client a project summary", "review rationale.md", or "make the client-facing overview safer".

PetriLahdelma/project-spine · 57 tokens

project-spine-template

Use when the user wants to apply a bundled, user-local, or project-local template to a new project, or save the current project as a reusable template. Phrases like "use our agency starter", "save this as a template for future clients", "apply the shared saas-marketing starter".

PetriLahdelma/project-spine · 66 tokens

project-spine-workspace

Use when the user asks about Project Spine hosted workspaces, team sync, shared workspace templates, invites, or commands such as spine login, spine workspace, spine publish, or spine drift check --push.

PetriLahdelma/project-spine · 55 tokens