domain-driven-design

Name: domain-driven-design
Author: techygarg

165stars12forks

How to install domain-driven-design?

techygarg/lattice/domain-driven-design

$npx -y skills add techygarg/lattice --skill domain-driven-design

Installs into the current project.

Summary

Apply DDD tactical patterns when working with domain code. Enforces aggregate design, value objects over primitives, entity identity rules, and bounded context boundaries. Use when creating or modifying domain models, designing aggregates, working in the domain layer, or when the

Files · 1

View on GitHub

SKILL.md

1	# Domain-Driven Design
2
3	## Config Resolution
4
5	Skill support project-custom. Resolution:
6
7	1. Look `.lattice/config.yaml` repo root
8	2. If found, check `paths.ddd_principles` custom doc path
9	3. If custom path exist, read doc, check YAML frontmatter `mode`:
10	- `mode: override` (or no mode): Custom doc full precedence.
11	Use instead embed default. Must comprehensive -- sole reference.
12	- `mode: overlay`: Read embed `./references/defaults.md` first, then apply
13	custom doc section on top. Section custom replace match
14	section default (match by heading). New section append after default.
15	4. If no config, no path, or path not found, read `./references/defaults.md`
16	5. Language adaptation: If `paths.language_idioms` exist in config, read "Type System & Object Model" section and adapt entity, value object, and aggregate implementation patterns to language constructs (e.g., struct vs class, trait vs interface, data class vs record). Language idioms take precedence over pseudocode defaults.
17
18	## Self-Validation Checklist
19
20	STOP after generating each component. Verify ALL before proceeding. STOP: If any check fails, fix before presenting. If check is a judgment call with multiple valid approaches (see Ambiguity Signals), flag — present options and reasoning rather than silently choosing.
21
22	1. ENTITY VS VALUE OBJECT: Each domain object — business track individual instance over time? Yes → entity with identity. No → value object with immutable and self-validate.
23	2. AGGREGATE BOUNDARY: Transactional invariant require this object inside aggregate? If not → separate aggregate reference by ID.
24	3. RICH BEHAVIOR: Entity have method enforce business rule, guard state transition, raise event? If entity just data holder → move logic from service into entity.
25	4. VALUE OBJECT COVERAGE: Scan primitive type should be value object — string email, number amount, raw UUID as identifier → wrap value object with validate.
26	5. AGGREGATE COHESION: List business rule root enforce. Each internal entity participate least one invariant? If not → belong own aggregate.
27	6. DOMAIN EVENTS: Domain event raise for state transition other aggregate react, change trigger notification, audit/compliance requirement? Don't raise event internal change nothing react.
28	7. DOMAIN SERVICE: Stateless logic span multiple entity place domain service rather than application service? Avoid I/O and infrastructure call?
29	8. FACTORY: Complex aggregate creation encapsulate factory method (`Order.create(...)`) or standalone factory class? Initial creation and reconstitution from persistence handle separate?
30
31	## Active Anti-Pattern Scan
32
33	After verify checklist above, scan output these specific anti-pattern. If find any, fix before present code.
34
35	- [ ] Anemic Domain Model: Entity data holder only getter/setter; all logic live service → move business rule into entity and value object
36	- [ ] Primitive Obsession: Raw string for email, number for money, UUID for ID → wrap value object with validate and behavior
37	- [ ] God Aggregate: Aggregate many entity, slow load, high contention → decompose keep only what share transactional invariant
38	- [ ] Cross-Aggregate Transaction: Service update two aggregate one transaction → use domain event eventual consistency
39	- [ ] Leaking Domain Logic: Business rule in controller, application service, or infrastructure → extract domain object or domain service
40	- [ ] Misidentified Entity/Value Object: Entity without lifecycle, or value object with identity track → apply identity test
41
42	## Ambiguity Signals
43
44	- Aggregate Boundary Size: Small aggregate (more event, eventual consistency) vs large aggregate (simple transaction, immediate consistency). Neither inherent correct — depend contention pattern and invariant scope.
45	- Entity vs Value Object: Some concept (like `Address` or `Money`) may or may not need identity depend domain complexity. Apply identity test, but acknowledge when borderline.
46	- Domain Service vs Entity Method: Logic span multiple entity could live domain service or be method on primary entity. Choice depend which entity "own" invariant.
47	- Object Creation Pattern: Factory method on aggregate root, standalone factory class, builder pattern, or plain constructor — depend assembly complexity and team convention. Don't prescribe pattern; ask which approach team prefer.
48
49	## Scope Statement
50
51	Skill operate within single repo, single bounded context (e.g., one API -- Order, User, Pricing). Cover tactical DDD pattern only -- not s

People who liked this also viewed

6 picks

Type

domain-driven-design

165stars12forks

View on GitHub

How to install domain-driven-design?

techygarg/lattice/domain-driven-design

$npx -y skills add techygarg/lattice --skill domain-driven-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Domain-Driven Design
2
3	## Config Resolution
4
5	Skill support project-custom. Resolution:
6
7	1. Look `.lattice/config.yaml` repo root
8	2. If found, check `paths.ddd_principles` custom doc path
9	3. If custom path exist, read doc, check YAML frontmatter `mode`:
10	- `mode: override` (or no mode): Custom doc full precedence.
11	Use instead embed default. Must comprehensive -- sole reference.
12	- `mode: overlay`: Read embed `./references/defaults.md` first, then apply
13	custom doc section on top. Section custom replace match
14	section default (match by heading). New section append after default.
15	4. If no config, no path, or path not found, read `./references/defaults.md`
16	5. Language adaptation: If `paths.language_idioms` exist in config, read "Type System & Object Model" section and adapt entity, value object, and aggregate implementation patterns to language constructs (e.g., struct vs class, trait vs interface, data class vs record). Language idioms take precedence over pseudocode defaults.
17
18	## Self-Validation Checklist
19
20	STOP after generating each component. Verify ALL before proceeding. STOP: If any check fails, fix before presenting. If check is a judgment call with multiple valid approaches (see Ambiguity Signals), flag — present options and reasoning rather than silently choosing.
21
22	1. ENTITY VS VALUE OBJECT: Each domain object — business track individual instance over time? Yes → entity with identity. No → value object with immutable and self-validate.
23	2. AGGREGATE BOUNDARY: Transactional invariant require this object inside aggregate? If not → separate aggregate reference by ID.
24	3. RICH BEHAVIOR: Entity have method enforce business rule, guard state transition, raise event? If entity just data holder → move logic from service into entity.
25	4. VALUE OBJECT COVERAGE: Scan primitive type should be value object — string email, number amount, raw UUID as identifier → wrap value object with validate.
26	5. AGGREGATE COHESION: List business rule root enforce. Each internal entity participate least one invariant? If not → belong own aggregate.
27	6. DOMAIN EVENTS: Domain event raise for state transition other aggregate react, change trigger notification, audit/compliance requirement? Don't raise event internal change nothing react.
28	7. DOMAIN SERVICE: Stateless logic span multiple entity place domain service rather than application service? Avoid I/O and infrastructure call?
29	8. FACTORY: Complex aggregate creation encapsulate factory method (`Order.create(...)`) or standalone factory class? Initial creation and reconstitution from persistence handle separate?
30
31	## Active Anti-Pattern Scan
32
33	After verify checklist above, scan output these specific anti-pattern. If find any, fix before present code.
34
35	- [ ] Anemic Domain Model: Entity data holder only getter/setter; all logic live service → move business rule into entity and value object
36	- [ ] Primitive Obsession: Raw string for email, number for money, UUID for ID → wrap value object with validate and behavior
37	- [ ] God Aggregate: Aggregate many entity, slow load, high contention → decompose keep only what share transactional invariant
38	- [ ] Cross-Aggregate Transaction: Service update two aggregate one transaction → use domain event eventual consistency
39	- [ ] Leaking Domain Logic: Business rule in controller, application service, or infrastructure → extract domain object or domain service
40	- [ ] Misidentified Entity/Value Object: Entity without lifecycle, or value object with identity track → apply identity test
41
42	## Ambiguity Signals
43
44	- Aggregate Boundary Size: Small aggregate (more event, eventual consistency) vs large aggregate (simple transaction, immediate consistency). Neither inherent correct — depend contention pattern and invariant scope.
45	- Entity vs Value Object: Some concept (like `Address` or `Money`) may or may not need identity depend domain complexity. Apply identity test, but acknowledge when borderline.
46	- Domain Service vs Entity Method: Logic span multiple entity could live domain service or be method on primary entity. Choice depend which entity "own" invariant.
47	- Object Creation Pattern: Factory method on aggregate root, standalone factory class, builder pattern, or plain constructor — depend assembly complexity and team convention. Don't prescribe pattern; ask which approach team prefer.
48
49	## Scope Statement
50
51	Skill operate within single repo, single bounded context (e.g., one API -- Order, User, Pricing). Cover tactical DDD pattern only -- not s

People who liked this also viewed

6 picks

Type