domain-entity

Implements domain behaviour, invariants, and constructors on C# entities and aggregates.

23|10|Updated Aug 31, 2017
One-click install
npx skills add https://github.com/IntentArchitect/Intent.Modules --skill domain-entity-intentarchitect
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-entity
Source: https://github.com/IntentArchitect/Intent.Modules/tree/main/Tests/Accelerators/.agents/skills/domain-entity
Command: npx skills add https://github.com/IntentArchitect/Intent.Modules --skill domain-entity-intentarchitect

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain classes often ship with empty methods, NotImplementedException placeholders, and constructors that fail to establish valid objects, leaving business rules scattered or missing entirely. ## Core Features & Use Cases - Behaviour Implementation: Infers and implements missing methods, guards, and constructors on entities, aggregate roots, and value objects while protecting invariants. - Invariant Enforcement: Validates mandatory inputs, rejects impossible state transitions, and updates related fields together so objects cannot drift into invalid states. - Style Preservation: Aligns with the existing codebase conventions and avoids introducing MediatR, repositories, or extra abstractions unless already in use. - Use Case: Given a C# aggregate with a constructor that skips validation and a method throwing NotImplementedException, the Skill infers intent from names, guards, and comments, then implements coherent domain logic with a brief note on assumptions. ## Quick Start Ask the assistant to implement the missing behaviour and constructor validation on your domain entity class while keeping business rules inside the entity.

Frequently Asked Questions about domain-entity

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement missing methods on a C# domain entity?▼

Infer intent from method names, parameters, existing properties, guard clauses, and comments, then implement the smallest coherent set of domain rules. Enforce invariants at the point of state change and state any assumptions when intent is ambiguous.

How should constructors validate domain objects in DDD?▼

A public constructor or factory should establish a fully valid domain object by validating mandatory arguments and rejecting impossible states. Normalise values only when the model already suggests it or it is clearly required.

Should business rules live on entities or application services?▼

Keep business rules on the entity, aggregate root, or value object when they protect that type's own invariants. Move rules to application services only when they genuinely span multiple aggregates or external systems.

Does this approach add MediatR or repository dependencies to the domain?▼

No. The domain model stays free of infrastructure concerns, and MediatR, repositories, domain services, or events are only introduced when the codebase already uses them or the user explicitly requests them.

When should domain exceptions be used instead of standard exceptions?▼

Use meaningful domain exceptions only if the codebase already follows that pattern. Otherwise rely on standard argument or invalid operation exceptions to keep the model consistent with existing conventions.