m09-domain

Model C++ domain concepts and distinguish entities from value objects.

14|3|Updated Jan 25, 2026
One-click install
npx skills add https://github.com/13eholder/Modern-Cpp-Skills --skill m09-domain-13eholder
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: m09-domain
Source: https://github.com/13eholder/Modern-Cpp-Skills/tree/main/m09-domain
Command: npx skills add https://github.com/13eholder/Modern-Cpp-Skills --skill m09-domain-13eholder

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps avoid common domain-design mistakes in C++ such as confusing identity with value, accidentally enabling object slicing, exposing implementation details in headers, and allowing invalid object states through public fields.

Core Features & Use Cases

  • Clear Value vs Entity guidance: Decide when a type should be a copyable value object versus a non-copyable entity identified by an ID.
  • Ownership and Aggregates: Advice on owning children with unique_ptr or vectors and defining aggregate roots.
  • APIs and Encapsulation: Recommendations for enforcing invariants via private data and public methods, using Pimpl to reduce header coupling, and using strong typed IDs instead of raw integers.
  • Use Case: Design a User aggregate that holds Value Objects for Name and Address, uses a strong UserId, deletes copy operations on the Entity, and exposes repository interfaces for persistence.

Quick Start

Design a User type by making the ID a strong type, treating Name and Address as value objects, deleting the User copy constructor while allowing move, encapsulating invariants in private members exposed through methods, and owning child entities with unique_ptr.

Frequently Asked Questions about m09-domain

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

FAQPage Schema
How do I distinguish entities from value objects in C++ domain models?

In C++ domain models, entities should have deleted copy constructors and be identified by strong typed IDs, while value objects are copyable types representing concepts like Name or Address without identity.

When should I use the Pimpl idiom to hide implementation details in C++ headers?

Use the Pimpl idiom in C++ headers to reduce compile-time coupling and hide implementation details when designing business-facing domain models where encapsulating private invariants behind public methods is required.

What is the best way to define aggregate roots and ownership boundaries in C++?

Define aggregate roots in C++ by owning child entities with unique_ptr or vectors, establishing clear ownership boundaries that prevent invalid object states and accidental object slicing.

How do I prevent object slicing and invalid states in C++ domain design?

Prevent object slicing and invalid states in C++ domain design by deleting copy operations on entities, keeping data members private, and exposing invariants only through public method interfaces.

Can I use raw integers for entity IDs in C++ domain-driven design?

Avoid raw integers for entity IDs in C++ domain-driven design; instead, use strong typed IDs to prevent identity errors and distinguish entities from value objects at compile time.

How do I design a repository interface for a C++ aggregate?

Design a repository interface for a C++ aggregate by defining a User type with a strong UserId, treating Name and Address as value objects, and exposing persistence interfaces for the aggregate root.