[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DVNDF42JNATRK50CGSKR9B":3,"skill-same:01M6DVNDF42JNATRK50CGSKR9B":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6DVNDF42JNATRK50CGSKR9B","ddd-principles",null,"ACTIVATE when designing the domain layer in OOP languages — bounded contexts, aggregates, value objects, layer purity, ports\u002Fadapters, dependency direction. ACTIVATE for 'domain', 'DDD', 'hexagonal', 'ports and adapters', 'domain purity', 'bounded context', 'aggregate'. Provides cross-language OOP-style DDD principles. For functional-style DDD (immutable records, smart constructors, pipelines) see craft:ddd-fp-principles. Language-specific examples live in php-ddd-conventions, nest-ddd-conventions.","FabienSalles\u002Fclaude-marketplace","FabienSalles","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F937901?v=4","01M6DVJBD31CJKRB382FQFZ5FH","Fabien Salles","01M6DVJBQNY8Q18KJD1ESAD6TX",9,"MIT","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fcraft\u002Fskills\u002Fddd-principles\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"ddd principles","ddd","craft","style","live","conventions","domain","aggregates","objects","language","activate","pipelines","dependency","context","ports","oop","php","immutable","examples","2026-11-10 10:12:30",false,"---\nname: ddd-principles\ndescription: \"ACTIVATE when designing the domain layer in OOP languages — bounded contexts, aggregates, value objects, layer purity, ports\u002Fadapters, dependency direction. ACTIVATE for 'domain', 'DDD', 'hexagonal', 'ports and adapters', 'domain purity', 'bounded context', 'aggregate'. Provides cross-language OOP-style DDD principles. For functional-style DDD (immutable records, smart constructors, pipelines) see craft:ddd-fp-principles. Language-specific examples live in php-ddd-conventions, nest-ddd-conventions.\"\n---\n\n# DDD — Cross-Language OOP Principles\n\n> The **rules** below are language-agnostic OOP-style DDD. Language-specific examples (forbidden imports, Symbol tokens, module structure) live in:\n> - `php-ddd-conventions` (PHP \u002F Symfony)\n> - `nest-ddd-conventions` (TypeScript \u002F NestJS)\n>\n> For **functional-style** DDD (immutable records, curried operations, Result pipelines), see `craft:ddd-fp-principles`.\n\n## 1. Domain Layer Purity\n\nThe domain layer contains **business logic only**. Infrastructure leaks into the domain are the most common architectural violation — they make the domain untestable without the framework and impossible to reuse.\n\n### Forbidden in the Domain Layer\n\n- Framework HTTP types (`Request`, `Response`, framework `UploadedFile`, etc.)\n- ORM \u002F database classes (Doctrine entities, Drizzle schemas, Prisma client)\n- DI decorators \u002F framework annotations (`@Injectable`, `@Module`, `@Inject`, etc.)\n- Framework-specific validators\n- Any external library tied to a framework\n\n### Allowed in the Domain Layer\n\n- Pure language types (string, int, Date, plain record, etc.)\n- Domain value objects (immutable, no framework dependency)\n- Domain interfaces (defined in domain, implemented in infrastructure)\n- Shared DTOs from contracts packages (typically `packages\u002Fshared` or equivalent)\n- Enums \u002F constant unions \u002F branded types\n\n**Criterion:** if the domain layer compiles WITHOUT the framework, it's pure.\n\n## 2. Ports & Adapters\n\nThe boundary between domain and infrastructure is a set of **interfaces (ports)** defined in the domain, implemented as **adapters** in the infrastructure.\n\n- Ports = pure interfaces, in the domain layer\n- Adapters = concrete implementations, in the infrastructure layer\n- The domain depends only on its own interfaces\n- The infrastructure imports the domain — never the reverse\n\n## 3. Dependency Direction (always inward)\n\n```\nControllers \u002F HTTP   →   Use Cases   →   Domain Services   →   Domain Ports\n                                                                     ↑\n   Infrastructure Adapters (DB, HTTP clients, …) ───────────────────┘\n        (implement the domain ports)\n```\n\n**Rule:** dependencies always flow **inward** toward the domain. Outer layers know about inner layers; inner layers know nothing about outer layers.\n\n## 4. Bounded Contexts\n\nA bounded context is a clearly delimited part of the system with its **own ubiquitous language**. Each bounded context maps to a separate module \u002F namespace \u002F directory.\n\n- 1 bounded context = 1 module (NestJS) \u002F 1 namespace (PHP) \u002F 1 directory (others)\n- Bounded contexts communicate through explicit contracts (DTOs, events) — never by sharing internals\n\n## 5. Aggregates\n\nAn aggregate is a state-bearing cluster of domain objects with:\n\n- A single **transactional boundary** — all invariants of the aggregate must hold at commit time.\n- A single **aggregate root** with an identity.\n- External references go through the root only.\n\n## 6. Value Objects\n\nValue objects are defined by their **attributes**, not by an identity:\n\n- **Immutable** (use `readonly` \u002F `final readonly` \u002F equivalent).\n- Equality is by attribute equality, not by reference.\n- May enforce invariants in the constructor (positive amount, valid format, etc.).\n\n## Quick Reference\n\n| Rule | Principle |\n|------|-----------|\n| Domain purity | No framework \u002F ORM \u002F HTTP in the domain layer |\n| Ports & adapters | Interfaces in domain, implementations in infrastructure |\n| Dependency direction | Always inward toward the domain |\n| Bounded context | 1 module \u002F namespace \u002F directory per context |\n| Aggregate | Single transactional boundary + identified root |\n| Value object | Immutable, equality by attributes, may enforce invariants |\n","# DDD — Cross-Language OOP Principles\n\n> The **rules** below are language-agnostic OOP-style DDD. Language-specific examples (forbidden imports, Symbol tokens, module structure) live in:\n> - `php-ddd-conventions` (PHP \u002F Symfony)\n> - `nest-ddd-conventions` (TypeScript \u002F NestJS)\n>\n> For **functional-style** DDD (immutable records, curried operations, Result pipelines), see `craft:ddd-fp-principles`.\n\n## 1. Domain Layer Purity\n\nThe domain layer contains **business logic only**. Infrastructure leaks into the domain are the most common architectural violation — they make the domain untestable without the framework and impossible to reuse.\n\n### Forbidden in the Domain Layer\n\n- Framework HTTP types (`Request`, `Response`, framework `UploadedFile`, etc.)\n- ORM \u002F database classes (Doctrine entities, Drizzle schemas, Prisma client)\n- DI decorators \u002F framework annotations (`@Injectable`, `@Module`, `@Inject`, etc.)\n- Framework-specific validators\n- Any external library tied to a framework\n\n### Allowed in the Domain Layer\n\n- Pure language types (string, int, Date, plain record, etc.)\n- Domain value objects (immutable, no framework dependency)\n- Domain interfaces (defined in domain, implemented in infrastructure)\n- Shared DTOs from contracts packages (typically `packages\u002Fshared` or equivalent)\n- Enums \u002F constant unions \u002F branded types\n\n**Criterion:** if the domain layer compiles WITHOUT the framework, it's pure.\n\n## 2. Ports & Adapters\n\nThe boundary between domain and infrastructure is a set of **interfaces (ports)** defined in the domain, implemented as **adapters** in the infrastructure.\n\n- Ports = pure interfaces, in the domain layer\n- Adapters = concrete implementations, in the infrastructure layer\n- The domain depends only on its own interfaces\n- The infrastructure imports the domain — never the reverse\n\n## 3. Dependency Direction (always inward)\n\n```\nControllers \u002F HTTP   →   Use Cases   →   Domain Services   →   Domain Ports\n                                                                     ↑\n   Infrastructure Adapters (DB, HTTP clients, …) ───────────────────┘\n        (implement the domain ports)\n```\n\n**Rule:** dependencies always flow **inward** toward the domain. Outer layers know about inner layers; inner layers know nothing about outer layers.\n\n## 4. Bounded Contexts\n\nA bounded context is a clearly delimited part of the system with its **own ubiquitous language**. Each bounded context maps to a separate module \u002F namespace \u002F directory.\n\n- 1 bounded context = 1 module (NestJS) \u002F 1 namespace (PHP) \u002F 1 directory (others)\n- Bounded contexts communicate through explicit contracts (DTOs, events) — never by sharing internals\n\n## 5. Aggregates\n\nAn aggregate is a state-bearing cluster of domain objects with:\n\n- A single **transactional boundary** — all invariants of the aggregate must hold at commit time.\n- A single **aggregate root** with an identity.\n- External references go through the root only.\n\n## 6. Value Objects\n\nValue objects are defined by their **attributes**, not by an identity:\n\n- **Immutable** (use `readonly` \u002F `final readonly` \u002F equivalent).\n- Equality is by attribute equality, not by reference.\n- May enforce invariants in the constructor (positive amount, valid format, etc.).\n\n## Quick Reference\n\n| Rule | Principle |\n|------|-----------|\n| Domain purity | No framework \u002F ORM \u002F HTTP in the domain layer |\n| Ports & adapters | Interfaces in domain, implementations in infrastructure |\n| Dependency direction | Always inward toward the domain |\n| Bounded context | 1 module \u002F namespace \u002F directory per context |\n| Aggregate | Single transactional boundary + identified root |\n| Value object | Immutable, equality by attributes, may enforce invariants |\n",{"name":5,"description":7},"main","479b264ec17cc5fafbf36287a1087472d3a386d3","plugins\u002Fcraft\u002Fskills\u002Fddd-principles",2,"https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace","https:\u002F\u002Fgithub.com\u002FFabienSalles","https:\u002F\u002Ffabiensalles.com","2026-10-13 04:33:22",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add FabienSalles\u002Fclaude-marketplace --skill ddd-principles",{"tool":57,"command":58},"bunx","bunx skills add FabienSalles\u002Fclaude-marketplace --skill ddd-principles",{"tool":60,"command":61},"pnpm","pnpm dlx skills add FabienSalles\u002Fclaude-marketplace --skill ddd-principles","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fcraft\u002Fskills\u002Fddd-principles\u002FSKILL.md",true,[],[66,96,114,134,154,168],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":77,"publishedAt":38},"01M6DW2YS1MGF65JNS1QQ15QHS","vitest-test-conventions","ACTIVATE when writing Vitest tests, creating test files, using vi.fn()\u002Fvi.mock()\u002Fvi.spyOn(), or test factories. ACTIVATE for 'Vitest', 'it.each', 'NestJS testing module', 'supertest', 'vi.fn', 'vi.mock', 'spyOn'. Provides Vitest\u002FNestJS-specific testing patterns; cross-language testing principles (DAMP, AAA, spy over mock, what NOT to test) live in craft:testing-principles. DO NOT use for: node:test files (a file importing node:test) or a project whose tests run under node --test (see node-test:node-test-conventions), TDD workflow\u002Fiterations (see vitest:vitest-tdd-workflow), PHP\u002FPHPUnit tests (see phpunit:php-test-conventions).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fvitest\u002Fskills\u002Fvitest-test-conventions\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[78,79,24,80,81,82,83,84,85,86,87,88,89,29,90,91,92,93,94,95],"test","vitest","vitest test conventions","testing","writing","tdd","workflow","file","testing patterns","use","files","nestjs","do","project","tests","module","fn","testing principles",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":38},"01M6DW2VFE6NPFCGQKQ68P1MVZ","vitest-tdd-workflow","ACTIVATE when building new features, endpoints, or user stories using TDD with Vitest in a TypeScript\u002FNestJS context. ACTIVATE for '\u002Ffeature-tdd-dev', 'TDD', 'red-green-refactor' in TS context. Provides Vitest\u002FNestJS-specific TDD examples and commands; cross-language TDD workflow (cross-layer iterations, RED-GREEN-REFACTOR, working app, bug-fix-first-test, mocks-hiding-bugs) lives in craft:tdd-workflow-principles. DO NOT use for: node:test files (a file importing node:test) or a project whose tests run under node --test (see node-test:node-test-conventions), test writing conventions (see vitest:vitest-test-conventions), PHP TDD (see phpunit:php-tdd-workflow).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fvitest\u002Fskills\u002Fvitest-tdd-workflow\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000023","Skill与智能体开发",[83,84,106,79,107,82,108,85,37,109,87,110,88,29,90,111,91,92,112,113],"tdd workflow","vitest tdd workflow","dev","fix","red-green-refactor","green","feature","app",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":38},"01M6DW2RGMQE10D8C5Z5MA2RMY","ts-refactoring","ACTIVATE when refactoring TypeScript code. ACTIVATE for 'refactor', 'extract', 'redesign', 'simplify', or 'clean up' in a TypeScript \u002F Node \u002F NestJS context. This skill provides TS-specific examples for the cross-language refactoring rules defined in craft:refactoring-principles. DO NOT use for: writing new features from scratch, general OOP patterns (see ts-oop).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-refactoring\u002FSKILL.md",[],[121,122,82,123,124,37,125,126,127,128,129,87,130,131,132,89,21,29,90,133],"refactoring","ts refactoring","typescript","code","refactor","simplify","Rules","node","redesign","up","general","clean","patterns",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":38},"01M6DW2MHYXNBBVYEGB058Y48J","ts-ports-adapters","ACTIVATE when a TypeScript codebase with no dependency-injection container has to declare a port and wire its adapter — a repository, a clock, an id generator, an event dispatcher the domain depends on. ACTIVATE for 'port', 'adapter', 'SPI', 'dependency inversion' or 'composition root' in a codebase that wires its dependencies by hand. Covers: the port as a type of functions in the domain layer, the adapter as an object literal annotated with it, the handler that takes its dependencies first and its data second, the composition root in the infrastructure layer, and the in-memory stub that substitutes for the adapter in a unit test. DO NOT use for: NestJS, or any container-based DI with decorators and tokens (see nest-ddd-conventions), aggregate operations and smart constructors (see ddd-ts-fp), the Result type itself (see ts-functional).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-ports-adapters\u002FSKILL.md",[140],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[33,142,143,78,20,144,87,145,146,89,147,29,90,148,25,149,150,151,152,153],"ts ports adapters","memory","Composition","container","functions","Literal","dependency-injection","tokens","as","type","id","adapter",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":38},"01M6DW2GRXZFYT05HEDB26C9B8","ts-oop","ACTIVATE when designing TypeScript classes, and the value objects or collections modelled as classes, or when the user asks about object design, encapsulation, Tell Don't Ask, or Symbol.iterator. Provides TS-specific examples for the cross-language OOP rules defined in craft:oop-principles, plus TS-specific patterns (Symbol.iterator, branded types for primitive identifiers). DO NOT use for: a value object or an aggregate modelled as an immutable record rather than a class (see ddd-ts-fp), refactoring methodology (see ts-refactoring).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-oop\u002FSKILL.md",[],[34,161,162,123,20,37,163,36,121,127,164,87,165,21,29,90,27,166,167,150],"ts oop","design","methodology","ask","refactoring methodology","record","collections",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":38},"01M6DW2D26XG5MJMTP9MSE43S2","ts-layer-boundaries","ACTIVATE when wiring a Worker entry point, a Router, a controller, or a domain event consumer in a TypeScript CQRS codebase, or when deciding where a port belongs. ACTIVATE for 'composition root', 'layer boundary', 'ESLint zones', 'domain must not import infrastructure'. Covers: the *Worker.ts composition root, the curried consumer, Router wiring of command endpoints, the five-gesture controller, the domain-to-infrastructure import boundary enforced by ESLint, infrastructure-only ports, in-memory doubles for every port, the read-can-reach-write asymmetry, and read endpoints going through a domain handler. DO NOT use for: the port's own shape and adapter binding (see ts-ports-adapters), the Result type (see ts-functional), domain event structure (see ts-ddd-events).","https:\u002F\u002Fgithub.com\u002FFabienSalles\u002Fclaude-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Ftypescript\u002Fskills\u002Fts-layer-boundaries\u002FSKILL.md",[],[175,143,20,176,177,144,33,87,178,179,180,29,90,181,25,182,183,151,153,184],"ts layer boundaries","controller","boundary","router","only","endpoints","structure","cqrs","worker","import"]