realize-aggregate

Implements a DDD Aggregate root with confined invariants and invariant tests.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/lucolucus/mismagent --skill realize-aggregate-lucolucus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: realize-aggregate
Source: https://github.com/lucolucus/mismagent/tree/main/plugins/mismagent/skills/realize-aggregate
Command: npx skills add https://github.com/lucolucus/mismagent --skill realize-aggregate-lucolucus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain invariants often get scattered across services and duplicated in application code, causing inconsistent business rules and concurrency bugs. This Skill guides the implementation of a single Aggregate root that owns its invariants in one place, tested once, with state protected from outside mutation. ## Core Features & Use Cases - Invariant ownership: Writes each declared invariant exactly once inside the Aggregate root, with one invariant-test per invariant translating the user's natural-language tests (tests_nl) into executable contract tests. - State confinement: Enforces private setters, named predicates instead of raw field exposure, soft-delete only, and primitive/Published Language identity at the boundary. - Concurrency correctness: Requires genuinely multi-threaded contention tests for any concurrency claim and guards against check-then-act (TOCTOU) bugs with atomic all-or-nothing operations. - Use Case: When a building-block manifest marks a block as type = aggregate — for example a Product block with the rule "a deactivated product cannot be sold" — the worker loads this Skill to produce the root, its value objects, and JVM-safe INV-n tagged tests that stay green on their own. ## Quick Start Ask the worker to realize the aggregate block from your building-blocks manifest, for example: implement the Product aggregate with its invariants and invariant tests.

Frequently Asked Questions about realize-aggregate

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

FAQPage Schema
How do I implement a DDD Aggregate root with invariants?

Place every invariant inside the Aggregate root as a method with private-setter state, and write one invariant-test per declared invariant. Application services call the root's methods instead of re-implementing the rules, so each rule exists exactly once.

How to test concurrency invariants like preventing oversell?

Write a genuinely multi-threaded test: release N threads or coroutines from a start barrier against the same instance, proven fail-before and pass-after the synchronization lands. Two sequential calls do not encode a concurrency claim and can merge an oversell bug.

Should an Aggregate expose its internal state fields to consumers?

No. Fields that embody an invariant stay private, and the Aggregate exposes a named predicate (like vendibile) instead of the raw field. Consumers ask the predicate rather than re-deciding the rule from raw reads.

Can an Aggregate expose its strong identity type at the boundary?

No. Identity at the boundary is primitive or Published Language, such as an Int or a shared kernel. The value class or strong identity type stays internal to the context to avoid coupling consumers to your domain model.

Why do invariant test names need an INV-n prefix without brackets?

The INV-n prefix makes per-block coverage checks a mechanical grep. Brackets and characters like dots, colons, or slashes do not compile in JVM method names, even inside backticks, so the tag must be plain text.