ddd

Model .NET domain business rules with aggregates, value objects, and domain events.

224|87|Updated Dec 15, 2018
One-click install
npx skills add https://github.com/Resgrid/Core --skill ddd-resgrid
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ddd
Source: https://github.com/Resgrid/Core/tree/main/.opencode/skills/ddd
Command: npx skills add https://github.com/Resgrid/Core --skill ddd-resgrid

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Domain-Driven Design (DDD) helps you model complex business rules by defining clear consistency boundaries, expressing domain concepts as validated value objects, and using domain events to decouple side effects from core invariants.

Core Features & Use Cases

  • Aggregates for consistency boundaries: Enforce invariants within an aggregate in a single transaction while allowing eventual consistency across aggregates.
  • Value Objects over primitives: Replace primitive obsession with immutable, validated C# record value objects for correct equality and behavior.
  • Domain events for meaningful state changes: Raise domain events inside aggregates and handle side effects after persistence to keep the domain model focused.
  • Aggregate root as the single entry point: Ensure external code can only interact through the root entity to maintain rules and prevent invalid states.
  • Repository per aggregate root: Persist aggregates as a whole (not child entities) using a repository boundary for aggregate persistence.

Quick Start

Load the ddd skill when implementing DDD for a .NET domain and design an aggregate root with validated value objects and domain events to represent your business workflow.

Frequently Asked Questions about ddd

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

FAQPage Schema
How do I model domain events and aggregate roots in .NET?

Aggregate roots in .NET serve as single entry points enforcing invariants. You raise domain events inside aggregates and dispatch them after persistence, decoupling side effects from core domain logic.

When do I need bounded contexts and aggregate consistency boundaries?

You need bounded contexts and aggregate consistency boundaries when complex business rules require strict transactional invariants within a single aggregate while allowing eventual consistency across multiple aggregates.

How do I implement value objects with strongly-typed IDs in C#?

Implement value objects with strongly-typed IDs in C# using immutable records with built-in validation. This replaces primitive obsession and ensures correct equality and behavior for domain concepts.

What is the best way to persist aggregates using a repository pattern?

The best way to persist aggregates is using a repository-per-aggregate-root pattern. This boundary saves the entire aggregate as a whole, preventing invalid states from external code directly modifying child entities.

Does domain-driven design work for decoupling side effects from invariants?

Domain-driven design works for decoupling side effects by raising domain events inside aggregates. Side effects are handled after persistence or transaction completion, keeping the domain model focused on invariants.

Why should external code only interact through the aggregate root?

External code should only interact through the aggregate root to maintain business rules and prevent invalid states. Directly accessing child entities bypasses the consistency boundaries and breaks invariants.