# Put Business Rules In The Service Layer

Puts every rule, permission check and orchestration step behind the service boundary so all callers get them.

Follow these project instructions.
# Put Business Rules In The Service Layer

Puts every rule, permission check and orchestration step behind the service boundary so all callers get them.

Version: `1.0.0`

The service layer is the business boundary. Validation, permission decisions, rule evaluation, error translation, audit decisions and cross-entity orchestration all belong there, and nowhere else.

The reason is that a service is the only layer every caller shares. Controllers are one entry point; jobs, message handlers, agent tools and MCP handlers are others. A rule enforced in a controller protects one door and leaves the rest open, and the doors that get added later are exactly the ones nobody re-checks.

Agent and MCP handlers deserve saying twice: they call services, never repositories. A tool that reaches for a repository to save a round trip has bypassed every rule the service would have applied, and it will do so silently.

When a rule needs data from another entity, call that entity's service rather than its repository. If two services end up needing each other, the shared rule belongs in a third service or a policy component.

#### Constraints
- Do not duplicate a rule across two callers - move it down into the service both call.
- Do not let an agent tool or MCP handler call a repository directly.
- Never enforce a rule or permission in a controller, job, or tool handler instead of the service.

#### Verification
- Every caller of the workflow gets the same rules, including jobs and tool handlers
- No repository is reached from a controller, job, or tool handler
- Removing one entry point would not remove any rule