Service Layer Architecture

Overview

This collection prefers a two-layer separation: actions orchestrate domain rules, while services implement reusable operations. Use it where the project has no established convention. Preserve existing domain services, repositories, transaction boundaries, and framework patterns when they already fit the task.

This prevents duplicated code, inconsistent behavior, and bugs fixed in one path but not others.

When to Use

• Multiple callers need the same low-level operation (sandbox creation, email sending, payment processing)
• You're copy-pasting operational logic between action files
• A bug fix in one workflow doesn't propagate to others doing the same thing
• Adding a new feature that shares mechanics with existing flows

Avoid extraction that adds indirection without a concrete benefit. Repetition is a useful signal, but a single caller can justify a boundary for testing, provider isolation, transactions, or complex logic.

Core Pattern

Orchestration Layer (Actions)          Service Layer (Shared Mechanics)
├── owns business rules                ├── owns reusable operations
├── owns state transitions             ├── owns provider/SDK interactions
├── owns auth/ownership checks         ├── owns command execution details
├── owns failure classification        ├── owns health checks / readiness
├── owns retries / user-facing errors  └── returns structured results
└── calls service functions

Rule of thumb:

• "What this product flow means" → keep in actions
• "How to do this operation reliably" → move to service layer

Quick Reference