domain-logic-module_skill

Overview

This skill extracts or adds domain rules into a focused, testable module so business invariants live at a clear boundary. It produces modules with explicit inputs/outputs, deterministic error behavior, and accompanying unit tests. The goal is to keep controllers, jobs, and adapters thin and free of core business logic.

How this skill works

I locate the appropriate domain boundary in your codebase and define a public API (functions or classes) with explicit types. Invariants are encoded as preconditions and, where meaningful, postconditions; errors are returned as typed, deterministic results aligned to any shared error taxonomy. I then add unit tests that exercise the happy path, invariant violations, and at least one edge case.

When to use it

• When business rules are sprinkled across controllers, jobs, or adapters
• When invariants are unclear or inconsistently enforced
• When you need deterministic error behavior for orchestration
• When tests fail to cover core domain rules or are hard to write
• When preparing logic for reuse by multiple callers

Best practices

• Pick an existing domain folder pattern, do not invent wide-reaching structure
• Design a minimal public API with clear input/output types and return-value errors
• Validate preconditions early and enforce postconditions where useful
• Use typed error codes instead of throwing raw exceptions across boundaries
• Write focused unit tests that prove rules, not wiring; mock dependencies via interfaces

Example use cases

• Encapsulate pricing or discount rules so payments and checkout call a single deterministic module
• Refactor eligibility checks currently duplicated in endpoints and background jobs
• Create a domain module that enforces quotas and returns explicit error codes for callers to act on
• Add invariants for state transitions (e.g., order -> shipped) with tests for illegal transitions
• Extract validation-heavy creation logic so integration adapters can rely on a single source of truth