business-logic
Business Logic
Goal
Define business logic as the rules, algorithms, and workflows in software that govern how data is created, stored, and transformed so real business policies become automated actions.
Treat business logic as purpose-driven code. The key question is not where the code lives, but whether the code expresses a business rule, business decision, business constraint, or business workflow.
What Counts as Business Logic
Classify code as business logic when it does one or more of these things:
- applies a business rule or policy
- makes a business decision from domain data
- calculates a business outcome with domain meaning
- enforces a business constraint or invariant
- changes data according to a business workflow
- controls status or lifecycle transitions with business meaning
- derives values that represent a business concept
- coordinates a sequence of domain actions required by a business process
Business logic often appears in code that answers questions such as:
- whether something is allowed
- how something must be priced, approved, assigned, scheduled, ranked, or settled
- when data can be created, updated, completed, cancelled, renewed, or expired
- which values must be produced from business inputs
Detection Workflow
-
Read the code for business meaning first.
- Look for domain terms, business concepts, policy names, state names, and vocabulary used by the product, company, or industry.
- Pay attention to rules that would matter even if the implementation language or framework changed.
-
Identify the business outcome controlled by the code.
- Determine what business decision or business state change the code produces.
- Check whether the code changes how data is created, stored, or transformed in a way that reflects a real policy or workflow.
-
Trace the rule to inputs, decisions, and outputs.
- Identify the domain inputs the rule depends on.
- Identify the conditions, thresholds, formulas, transitions, and side effects that carry business meaning.
- Identify the resulting domain state, persisted data, or downstream action.
-
Prefer semantic classification to file or framework conventions.
- Do not assume code is or is not business logic only because of its folder, class name, framework role, or transport boundary.
- Classify by what the code means for the business.
Writing or Changing Business Logic
-
Preserve the business meaning before refactoring.
- Restate the rule in plain language before changing the code.
- Keep domain terms explicit in names, branches, and data structures.
-
Make business decisions legible.
- Express thresholds, formulas, eligibility checks, lifecycle transitions, and workflow steps clearly.
- Prefer code shapes that reveal the rule instead of hiding it behind incidental implementation detail.
-
Keep business rules explicit.
- Avoid scattering one rule across many unrelated edits when a cohesive expression is possible.
- When multiple steps form one workflow, keep the sequence understandable as a single business process.
-
Protect domain invariants.
- Verify that edited code still enforces the required business constraints.
- Verify that transformed or persisted data still matches the intended business outcome.
Review Questions
When reading or reviewing code, ask:
- What business rule or policy is encoded here?
- What business decision does this branch, formula, or workflow make?
- Which domain inputs drive that decision?
- What business state or business data changes as a result?
- Would a change here alter real business behavior?
If the answer is yes, treat the code as business logic.
Report the Outcome
When finishing the task:
- state which code was identified or treated as business logic
- state which business rules, algorithms, or workflows were implemented or preserved
- state which business inputs, decisions, and outcomes were affected
More from code-sherpas/agent-skills
neverthrow-return-types
Require `neverthrow`-based return types in TypeScript and JavaScript code whenever the surrounding technology allows it. Use when creating, refactoring, reviewing, or extending standalone functions, exported module functions, class methods, object methods, service methods, repository methods, and similar APIs that should expose explicit success and failure result types in their signatures. Prefer `Result<T, E>` for synchronous code and `ResultAsync<T, E>` for asynchronous code. Only skip a `neverthrow` return type when a framework, library, runtime interface, or externally imposed contract is incompatible and requires a different return shape.
16neverthrow-wrap-exceptions
Capture exceptions and promise failures with `neverthrow` instead of hand-written `try/catch` in TypeScript and JavaScript code. Use when wrapping synchronous functions that may throw, promise-returning functions that may throw before returning, existing `PromiseLike` values that may reject, or third-party APIs such as parsers, database clients, HTTP clients, file-system helpers, serializers, and SDK calls. Prefer `Result.fromThrowable` for synchronous throwers, `ResultAsync.fromThrowable` for promise-returning functions that may throw or reject, and `ResultAsync.fromPromise` when you already have a `PromiseLike` value in hand. Only keep `try/catch` when the language construct, cleanup requirement, or framework boundary truly requires it.
11atomic-design
Create or update web UI components with a strict reuse-first workflow. Use when building, refactoring, restyling, or extending frontend or template components while minimizing raw DOM or HTML by reusing or generalizing existing components first.
10write-persistence-representations
Create or update persistence-layer data representations in any stack, including ORM entities, schema definitions, table mappings, document models, collection definitions, and similar database-facing code. Use when agents needs to add or change persisted fields, identifiers, relationships, indexes, timestamps, auditing fields, or storage mappings in frameworks, libraries, or ORMs such as Prisma, TypeORM, Sequelize, Drizzle, Mongoose, Hibernate/JPA, Doctrine, Ecto, Active Record, or equivalent persistence technologies.
7immutable-domain-entities
Require the immutable design pattern for domain entities. Use when an agent needs to create, modify, review, or interpret domain entities and should preserve identity while expressing state changes through new immutable instances. Domain entities must be modeled as immutable classes, not as plain type aliases or interfaces paired with standalone functions.
7update-agent-skills
Update agent skills installed with the `skills` CLI. Use when asked to refresh installed skills, keep a project's skills current, or troubleshoot cases where `npx skills update` reports that everything is up to date. For project-scoped installs, a no-change update must immediately run the bundled reinstall script so tracked skills from `skills-lock.json` are reinstalled without extra investigation.
7