mcpField
P
principle-model-the-domain

principle-model-the-domain

github.com/mariusflorescuDevelopment18119 installsUpdated 2w ago
Repository

About principle-model-the-domain

A coding skill for choosing data structures and module boundaries that reflect a domain. It helps developers reduce scattered conditionals and invalid states without adding abstractions where straightforward code is already clear.

Key features

  1. 01Represent lifecycles with state machines
  2. 02Use typed models for domain data
  3. 03Replace branching with registries or unions
  4. 04Group behavior around domain ownership
  5. 05Prefer simple code when abstractions add no value

Use cases

  1. 01Refactoring long conditional chains
  2. 02Modeling lifecycle and state transitions
  3. 03Organizing repeated domain rules
  4. 04Selecting collections for access patterns

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mariusflorescu/pstack-t3 --skill principle-model-the-domain

After installing, type/principle-model-the-domainin Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Model the Domain

Encode the real domain in a data structure instead of scattering it across conditionals. A structure that matches the domain makes invalid states unrepresentable and deletes branches. Choosing it at write time is cheap. Recovering it later reads as a refactor and gets deferred.

Reach for:

  • A state machine instead of scattered booleans, phases, or lifecycle checks.
  • A typed model instead of loose parameters or repeated shape assumptions.
  • A map, registry, lookup table, or discriminated union instead of branching spread across files.
  • A reducer or command/event model instead of ad hoc state mutations.
  • A module organized around one body of domain knowledge instead of a sequence such as load, validate, transform, and save. Execution order is not ownership.
  • A small module boundary that gathers repeated behavior, ownership, or invariants.
  • A queue, cache, index, graph, tree, or normalized collection where the access pattern calls for it.
  • Any other structure that fits. When none fits, work out what the code must never allow and how the data gets read, then find the structure that encodes exactly that.

Do not force an abstraction. Prefer boring code if the current shape is already clear, local, and unlikely to grow. Be skeptical of an abstraction that adds indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.

The sign that you skipped this is a new feature that grows an existing if/else chain by one more branch, or a second boolean that must stay in sync with the first. Temporal decomposition is another sign. Phase-named modules repeat the same domain rules across steps.

Comments

Markdown supported