service-business-logic

Define application service orchestration with authorization checks and transaction boundaries.

4|Updated May 16, 2026
One-click install
npx skills add https://github.com/machenjie/rd-skills --skill service-business-logic
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: service-business-logic
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/service-business-logic
Command: npx skills add https://github.com/machenjie/rd-skills --skill service-business-logic

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents application services from becoming fragile, insecure, and inconsistent by defining how to coordinate authorization, domain operations, persistence, events, and external effects within a clear use-case boundary.

Core Features & Use Cases

  • Authorization-first orchestration: Ensures policy checks happen before any repository read to avoid information disclosure and timing side channels.
  • Explicit transaction boundaries: Separates in-transaction domain/repository work from out-of-transaction external calls to prevent rollback-after-external-call inconsistencies.
  • Domain-invariant delegation: Keeps business rules in the domain layer so services don’t duplicate invariants and drift over time.
  • Anti-god-service guidance: Enforces single-responsibility use-case services rather than bundling unrelated workflows into one service.

Quick Start

Ask the agent to design a single bounded service method for your change scenario, including the authorization order, explicit transaction scope, domain calls, repository actions, event emission timing, and external-effect compensation plan.

Frequently Asked Questions about service-business-logic

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design application service orchestration to avoid becoming a god service?

To design application service orchestration without a god service, enforce single-responsibility use-case handlers that coordinate domain interactions, delegate business rules to the domain layer, and avoid bundling unrelated workflows into one service.

When should I perform authorization checks in an application service?

Authorization checks should happen before any repository read to prevent information disclosure and timing side channels. This ensures policy validation occurs prior to exposing domain data within the transaction boundary.

How do I handle transaction boundaries for external calls in application services?

Handle transaction boundaries by separating in-transaction domain and repository work from out-of-transaction external calls. This prevents rollback-after-external-call inconsistencies and requires explicit compensation and idempotency design for external effects.

When do I emit domain events in application service orchestration?

Emit domain events after the transaction commits to ensure coherence. This sequencing guarantees that event emission reflects successfully persisted state changes rather than potential rolled-back domain operations.

Do I need explicit compensation design for external effects in application services?

Explicit compensation design is required for external effects to maintain consistency. It ensures that failed external interactions are properly reversed or handled without leaving the system in an incoherent state.