intra-invariant

Name: intra-invariant
Availability: InStock
Author: socialsoftware

Add Layer 1 intra-invariants to aggregates via verifyInvariants() with tests.

5|2|Updated Jun 28, 2023

Search Tags:#consistency #aggregate #invariants #tests #unit-of-work #intra-invariant #verifyinvariants

Ready to run

npx skills add https://github.com/socialsoftware/microservices-simulator --skill intra-invariant

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: intra-invariant
Source: https://github.com/socialsoftware/microservices-simulator/tree/main/.claude/skills/intra-invariant
Command: npx skills add https://github.com/socialsoftware/microservices-simulator --skill intra-invariant

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill enables adding a Layer 1 intra-invariant to an existing aggregate to enforce a rule that must always hold within a single aggregate instance. It ensures consistency by hooking into the verifyInvariants() workflow so violations are detected during every Unit of Work commit.

Core Features & Use Cases

Define a private invariant helper named invariant<RuleName>() that returns a boolean indicating whether the invariant holds.
Wire the helper into verifyInvariants() with the appropriate state scope (ACTIVE vs ALL states) and throw an invariant violation when needed.
Update the INTRA-INVARIANTS block and add tests to cover both compliant and violated states.

Quick Start

Add a new intra-invariant on the target aggregate and wire it into the invariants checks.

Frequently Asked Questions about intra-invariant

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

FAQPage Schema

How do I enforce aggregate invariants during a Unit of Work commit?▼

Intra-aggregate invariants are consistency rules that must always hold within a single aggregate instance. They are enforced by hooking custom invariant helpers into the aggregate's verifyInvariants() workflow to detect violations during a Unit of Work commit.

How do I add a new invariant check to an existing aggregate?▼

To add a new invariant check to an existing aggregate, create a private invariant helper returning a boolean, wire it into verifyInvariants() with the correct state scope, update the INTRA-INVARIANTS block, and add compliance tests.

What is the difference between ACTIVE and ALL states when verifying invariants?▼

When verifying invariants, ACTIVE state scope checks the rule only against currently active aggregate instances, while ALL states evaluates the invariant across every state. You select the appropriate scope when wiring the helper into verifyInvariants().

Do I need to write tests when adding an intra-invariant to an aggregate?▼

Yes, you need to write tests when adding an intra-invariant to an aggregate. You must add tests covering both compliant states where the invariant holds and violated states where an invariant violation is expected to be thrown.

Why verify invariants on commit instead of during each state mutation?▼

Verifying invariants on commit during the Unit of Work ensures aggregate consistency regardless of the triggering operation. This approach centralizes rule enforcement and detects violations before data is persisted.