business-logic-entry-point-vocabulary
Business Logic Entry Point Vocabulary
Goal
Recognize the many names that software developers use in practice for business-logic entry points and treat them as synonyms for the same concept.
Developers, architects, and codebases frequently call business-logic entry points by different names depending on the tradition, framework, or architectural style they follow. These names all refer to the same idea: a function, method or class that a caller invokes to trigger business logic.
Common Names
The following terms are commonly used to refer to business-logic entry points:
- use case — from Clean Architecture and hexagonal architecture traditions
- application service — from Domain-Driven Design and layered architecture traditions
- service layer — from service-oriented and layered architecture traditions
- command handler — from CQS and CQRS traditions, for entry points that change state
- query handler — from CQS and CQRS traditions, for entry points that return data
- interactor — from Clean Architecture tradition
- facade — when used as the public interface to business operations
- action — used in some frameworks and codebases for entry points that perform a business operation
This list is not exhaustive. Other names may appear in specific communities, frameworks, or codebases. The key criterion is not the name but whether the code acts as the entry point where a caller triggers business logic.
Mapping Rule
-
When the user or codebase uses any of these names, treat the referenced code as a business-logic entry point.
- Apply all business-logic entry-point skills that are in scope.
- Do not require the code to be literally named "entry point" to recognize it.
-
When the user asks to create, modify, or review a use case, application service, command handler, query handler, interactor, or similar construct, interpret the request as work on a business-logic entry point.
- Apply the relevant entry-point skills such as CQS, handler signatures, payload types, typical domain-entity entry points, business constraints, and authentication constraints.
-
Do not enforce a single naming convention from this vocabulary.
- The project may use any of these names or its own equivalent.
- This skill maps vocabulary to concepts. Other skills govern naming conventions within the code.
Detection Workflow
-
Listen for vocabulary in user requests.
- Watch for terms like use case, application service, service layer, command handler, query handler, interactor, facade, or action.
- Treat these as references to business-logic entry points.
-
Scan the codebase for vocabulary in code structures.
- Look for classes, functions, modules, or files named with these terms.
- Treat matching code as business-logic entry points for the purpose of applying entry-point skills.
-
Do not rely on vocabulary alone for classification.
- Verify that the code actually acts as an entry point to business logic.
- A class named
Servicethat only does HTTP routing is not a business-logic entry point. A class namedUseCasethat orchestrates business rules is.
Review Questions
When reading or reviewing code, ask:
- Does this code use a name from the common vocabulary for business-logic entry points?
- Does it actually act as the entry point where a caller triggers business logic?
- Have all relevant business-logic entry-point skills been applied to it?
If the answer is yes, apply this skill.
Report the Outcome
When finishing the task:
- state which vocabulary term the user or codebase used
- state that it was recognized as a business-logic entry point
- state which business-logic entry-point skills were applied as a result
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.
7aggregate-boundaries
Determine and enforce aggregate boundaries when domain entities relate to other domain entities. Use when an agent needs to create, modify, review, or interpret a domain entity that references another domain entity. The agent must determine whether the related entities belong to the same aggregate or to different aggregates, apply the correct reference style — direct reference within the same aggregate, identity reference across aggregates — and document the boundary decision in the project's agent instructions file so future tasks reuse the same decision without asking again.
6business-logic-entry-point-repository-operations
Require repository interfaces to expose a standard set of operations with specific signatures and naming conventions. Use when an agent needs to create, modify, review, or interpret repository interfaces used by business-logic entry points. Repositories must offer findById (fails when entity is absent — never returns null or optional), create (returns created entity), update (returns updated entity), search (returns collection), and deleteById (returns nothing). Do not use a generic "save" operation — always distinguish between create and update explicitly.
6