aggregate-design

Enforce DDD aggregate boundaries and invariants during domain design reviews.

81|3|Updated Jan 14, 2026
One-click install
npx skills add https://github.com/j5ik2o/okite-ai --skill aggregate-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: aggregate-design
Source: https://github.com/j5ik2o/okite-ai/tree/main/.agent/skills/aggregate-design
Command: npx skills add https://github.com/j5ik2o/okite-ai --skill aggregate-design

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Designing domain models that keep aggregate boundaries and invariants is challenging and error-prone. aggregate-design provides structured, enforceable guidance for clustering related domain objects into stable aggregates and for ensuring the aggregate root maintains true invariants.

Core Features & Use Cases

  • Enforces Design by Contract style invariants within aggregate roots and common aggregate operations.
  • Encapsulates Evans Rules and Vernon’s Rules to guide repository access, boundary maintenance, and inter-aggregate references.
  • Supports design-time reviews and refactoring efforts to reduce coupling and improve the clarity of domain boundaries.

Quick Start

Start by auditing current aggregates to identify boundary violations and invariants, then update the domain model accordingly.

Frequently Asked Questions about aggregate-design

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

FAQPage Schema
How do I design aggregate boundaries that maintain true invariants in a DDD codebase?

To design aggregate boundaries with true invariants, you must cluster related domain objects into stable aggregates and enforce Design by Contract constraints within the aggregate root. This ensures boundary access and immutability considerations are strictly maintained.

What are Evans Rules and Vernon's Rules for aggregate root access?

Evans Rules and Vernon's Rules guide repository access and boundary maintenance by enforcing that inter-aggregate references rely on identity rather than direct object references. This encapsulation reduces coupling and clarifies domain boundaries across services.

How do I audit existing domain models for aggregate boundary violations?

Auditing domain models for aggregate boundary violations involves reviewing current aggregate clusters to identify broken invariants and improper root access. You then refactor the domain model to align with strict boundary maintenance and Design by Contract principles.

When should I refactor aggregate boundaries during a domain-driven design review?

You should refactor aggregate boundaries during a design review when inter-aggregate coupling increases or invariants are violated. Restructuring aggregate roots and boundary access patterns restores domain model clarity and enforces immutability constraints.

Can I use aggregate design principles for refactoring domain models across multiple services?

Aggregate design principles apply directly to refactoring domain models across multiple services. The guidance enforces consistent aggregate boundaries, root-entity access patterns, and invariant checks regardless of the service scope.

Why does my aggregate root fail to enforce domain invariants?

An aggregate root fails to enforce domain invariants when boundary access patterns are violated or related objects are improperly clustered. Applying Design by Contract constraints and strict root-entity encapsulation resolves these invariant failures.