domain-modeling

Design domain data shapes, invariants, and state transitions with effects isolated at boundaries.

1|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/kreek/consult --skill domain-modeling-kreek
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/kreek/consult/tree/main/plugin/skills/domain-modeling
Command: npx skills add https://github.com/kreek/consult --skill domain-modeling-kreek

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Codebases often allow illegal states to be represented through nullable fields, boolean flag combinations, and raw input passed deep into business logic, causing bugs that surface far from their source. This Skill guides agents to model data first so forbidden states become unrepresentable in the type system. ## Core Features & Use Cases - Invariant-first data design: Define data shapes, allowed state combinations, and transitions before writing transformations, using explicit variants instead of flags or nullables. - Boundary parsing discipline: Parse external input once at the edge into trusted internal types using ecosystem schema libraries like Pydantic or Zod. - Functional core, imperative shell: Keep effects such as I/O, clocks, randomness, and persistence at the edges so core logic tests run without mocks or databases. - Use Case: When adding a payment state machine to an invoicing service, use this Skill to model states like pending, settled, and expired as explicit variants, parse API payloads at the boundary, and keep database calls out of the domain functions. ## Quick Start Use the domain-modeling skill to design the data shapes and state transitions for this feature before writing any transformation code.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema
How do I make illegal states unrepresentable in my domain model?▼

Model allowed states as explicit variants or sum types instead of boolean flags or nullable combinations. If the type cannot express a forbidden state, callers cannot construct it, removing the need for defensive guards throughout the code.

How should I validate external input in a domain-driven design?▼

Parse external input once at the boundary into a trusted internal shape using the ecosystem's schema library, such as Pydantic in Python or Zod in TypeScript. Internal domain code should never handle raw strings or untyped maps.

Should I use floats to store monetary amounts?▼

Never use binary floats for money because 0.1 + 0.2 does not equal 0.3 in IEEE 754. Use Decimal, BigDecimal, or integer minor units, and always carry the ISO 4217 currency code alongside the amount.

When should I not use domain modeling rules?▼

Skip this approach for public HTTP contract details, physical database schema design, and broad refactoring sequences, which belong to API, database, and refactoring concerns. Disposable or purely local data shapes also do not need approval gates.

Why should domain logic avoid calling databases directly?▼

Effects like I/O, clocks, and persistence are contagious and make core logic untestable without mocks. Keep them in an imperative shell so the functional core stays pure and tests run without databases, network, or global time.