Application Services vs Use Cases: The Actual Difference
- Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
Two PHP engineers are reviewing a pull request. One says “this should be an application service.” The other says “no, a use case.” They argue for fifteen minutes, agree they mean the same thing, merge the PR, and the next sprint someone opens app/Services/OrderService.php and finds nineteen public methods, two private helpers, and four injected dependencies that only two of those methods actually use.
That argument repeats in every PHP codebase that imports clean or hexagonal vocabulary without locking down what the words mean. The terms are not interchangeable. They describe two different things at two different sizes. Once a team agrees on the distinction, “where does this code go” stops being a debate.
Here is the rule that ends it: an ApplicationService is a layer that holds related operations. A UseCase is a single operation: one verb, one class, one public method. Both are valid. Picking one is a project-wide decision, not a per-feature one.
What the two words actually point at
Eric Evans introduced application services in Domain-Driven Design (2003) as the thin orchestration layer that sits between the inbound side (controllers, CLI, queue workers) and the domain. Robert Martin used use cases in Clean Architecture (2017) for the same orchestration responsibility, but framed each one as its own object. Both authors agree on what the code does. They disagree on how to package it.
In a PHP codebase the difference shows up at the file level.
An ApplicationService groups verbs that share a noun:
final class OrderApplicationService
{
public function __construct(
private readonly OrderRepository $orders,
private readonly PaymentGateway $payments,
private readonly EventDispatcher $events,
private readonly Clock $clock,
) {}
public function create(CreateOrderCommand $cmd): OrderId { /* ... */ }
public function cancel(CancelOrderCommand $cmd): void { /* ... */ }
public function refund(RefundOrderCommand $cmd): void { /* ... */ }
}
A UseCase isolates one verb in its own class:
final class CreateOrderUseCase
{
public function __construct(
private readonly OrderRepository $orders,
private readonly Clock $clock,
) {}
public function execute(CreateOrderCommand $cmd): OrderId { /* ... */ }
}
The orchestration, dependency set, and domain boundary are identical. Only the packaging changes. That is the whole disagreement.
The worked example: three verbs, two packagings
Here is the same order feature written both ways, in PHP 8.3, against the same domain. The domain types and ports are constant across both versions; only the application layer changes.
Shared pieces first.
<?php
declare(strict_types=1);
namespace AppDomainOrder;
final readonly class OrderId
{
public function __construct(public string $value) {}
}
final class Order
{
public function __construct(
public readonly OrderId $id,
public readonly string $customerId,
public readonly int $totalCents,
public readonly DateTimeImmutable $createdAt,
private string $status,
) {}
public function cancel(): void
{
if ($this->status !== 'pending') {
throw new DomainException(
"cannot cancel order in status {$this->status}"
);
}
$this->status = 'cancelled';
}
public function refund(): void
{
if ($this->status !== 'paid') {
throw new DomainException(
"cannot refund order in status {$this->status}"
);
}
$this->status = 'refunded';
}
public function status(): string
{
return $this->status;
}
}
Two ports, one for persistence and one for the payment side.
<?php
declare(strict_types=1);
namespace AppApplicationPort;
use AppDomainOrderOrder;
use AppDomainOrderOrderId;
interface OrderRepository
{
public function save(Order $order): void;
public function get(OrderId $id): Order;
}
interface PaymentGateway
{
public function refund(OrderId $id, int $amountCents): void;
}
Three commands, one per verb.
<?php
declare(strict_types=1);
namespace AppApplicationCommand;
final readonly class CreateOrderCommand
{
public function __construct(
public string $customerId,
public int $totalCents,
) {}
}
final readonly class CancelOrderCommand
{
public function __construct(public string $orderId) {}
}
final readonly class RefundOrderCommand
{
public function __construct(public string $orderId) {}
}
Version A — one ApplicationService class with three verbs
<?php
declare(strict_types=1);
namespace AppApplicationService;
use AppApplicationCommandCancelOrderCommand;
use AppApplicationCommandCreateOrderCommand;
use AppApplicationCommandRefundOrderCommand;
use AppApplicationPortOrderRepository;
use AppApplicationPortPaymentGateway;
use AppDomainClock;
use AppDomainOrderOrder;
use AppDomainOrderOrderId;
final class OrderApplicationService
{
public function __construct(
private readonly OrderRepository $orders,
private readonly PaymentGateway $payments,
private readonly Clock $clock,
) {}
public function create(CreateOrderCommand $cmd): OrderId
{
$order = new Order(
id: new OrderId(bin2hex(random_bytes(8))),
customerId: $cmd->customerId,
totalCents: $cmd->totalCents,
createdAt: $this->clock->now(),
status: 'pending',
);
$this->orders->save($order);
return $order->id;
}
public function cancel(CancelOrderCommand $cmd): void
{
$order = $this->orders->get(new OrderId($cmd->orderId));
$order->cancel();
$this->orders->save($order);
}
public function refund(RefundOrderCommand $cmd): void
{
$order = $this->orders->get(new OrderId($cmd->orderId));
$order->refund();
$this->payments->refund($order->id, $order->totalCents);
$this->orders->save($order);
}
}
Notice what this version pays: every method has access to every constructor dependency, whether it needs it or not. create and cancel never touch $this->payments, but it is wired in regardless. That is the trade-off: convenience of grouping in exchange for looser dependency hygiene.
Version B — three UseCase classes, one verb each
<?php
declare(strict_types=1);
namespace AppApplicationUseCase;
use AppApplicationCommandCreateOrderCommand;
use AppApplicationPortOrderRepository;
use AppDomainClock;
use AppDomainOrderOrder;
use AppDomainOrderOrderId;
final class CreateOrderUseCase
{
public function __construct(
private readonly OrderRepository $orders,
private readonly Clock $clock,
) {}
public function execute(CreateOrderCommand $cmd): OrderId
{
$order = new Order(
id: new OrderId(bin2hex(random_bytes(8))),
customerId: $cmd->customerId,
totalCents: $cmd->totalCents,
createdAt: $this->clock->now(),
status: 'pending',
);
$this->orders->save($order);
return $order->id;
}
}
<?php
declare(strict_types=1);
namespace AppApplicationUseCase;
use AppApplicationCommandCancelOrderCommand;
use AppApplicationPortOrderRepository;
use AppDomainOrderOrderId;
final class CancelOrderUseCase
{
public function __construct(
private readonly OrderRepository $orders,
) {}
public function execute(CancelOrderCommand $cmd): void
{
$order = $this->orders->get(new OrderId($cmd->orderId));
$order->cancel();
$this->orders->save($order);
}
}
<?php
declare(strict_types=1);
namespace AppApplicationUseCase;
use AppApplicationCommandRefundOrderCommand;
use AppApplicationPortOrderRepository;
use AppApplicationPortPaymentGateway;
use AppDomainOrderOrderId;
final class RefundOrderUseCase
{
public function __construct(
private readonly OrderRepository $orders,
private readonly PaymentGateway $payments,
) {}
public function execute(RefundOrderCommand $cmd): void
{
$order = $this->orders->get(new OrderId($cmd->orderId));
$order->refund();
$this->payments->refund($order->id, $order->totalCents);
$this->orders->save($order);
}
}
Three files instead of one. Each class names exactly what it needs. CancelOrderUseCase has no idea PaymentGateway exists; CreateOrderUseCase does not pull in either of the other dependencies. The signature of each constructor is a precise inventory of the verb.
Side-by-side: what each style costs and pays for
| Property | ApplicationService (layer) | UseCase (per verb) |
|---|---|---|
| File count | 1 per noun | N per noun |
| Constructor scope | Union of all verbs’ deps | Exactly this verb’s deps |
| Where readers look first | The class | The folder listing |
| Testing setup | Mock everything per test | Mock only what this verb needs |
| Refactoring a single verb | Touches a shared class | Touches one isolated class |
| New verb on the same noun | Add a method | Add a file |
| Container wiring | One binding per noun | One binding per verb |
| Risk of God-class drift | Real, watch for it | Structurally hard |
| Risk of folder bloat | Low | Real at 50+ verbs |
| CQRS / handler buses fit | Awkward (1-to-many) | Native (1-to-1) |
Neither column is wrong. The right column is what Robert Martin draws on the whiteboard; the left column is what most Laravel and Symfony tutorials write. Teams get into trouble when half the codebase is one and half is the other.
How to pick one and stop arguing
Use ApplicationService when:
- The team is small and the surface area is small. Three to six verbs per noun, no plans to grow much.
- You are not running a command bus or a CQRS-style handler discovery. The orchestration entry point is the controller, and one injected service per noun is easier to wire than ten.
- The verbs share a lot of state-validation logic and pulling it into private methods on the same class is cleaner than extracting a shared collaborator.
- The team is new to clean/hexagonal vocabulary and you want a forgiving starting layer that won’t explode into hundreds of files in week two.
Use UseCase when:
- The team uses a command bus (Symfony Messenger, Tactician, a homemade one) and each command needs a single handler. The 1-to-1 mapping is exactly what these libraries expect.
- Constructor hygiene matters more than file count. Reviewers should see at a glance which ports a single operation touches.
- The codebase has fifty or more verbs across a few nouns and the would-be
OrderApplicationServiceis heading toward a thousand-line file with thirty dependencies. - You want a one-screen unit of work that can be reasoned about, tested, and replaced in isolation.
The team makes one of those calls, writes it into the project’s architecture doc, and stops debating it per-PR.
Two anti-patterns that ruin both styles
The God service. An OrderApplicationService with twenty-two public methods, fourteen injected dependencies, and a private function ensureOrderIsValid() that two-thirds of the methods call. This is the version everyone has met, and it is the reason people write angry blog posts about service layers. Renaming to UseCase changes nothing. The fix is to split the noun (OrderLifecycle, OrderRefunds, OrderFulfilment) or go per-verb.
The shadow service. A folder of UseCase classes where every class extends a BaseUseCase that injects a ServiceContainer and pulls dependencies out of it. The constructor lists nothing; the body calls $this->container->get(OrderRepository::class). This is an ApplicationService wearing a UseCase costume. It defeats the whole point: the constructor no longer tells you what the verb needs, and tests have to stub a container instead of passing two arguments. If the team picks UseCase, the constructor lists the real ports. Otherwise, pick ApplicationService and stop pretending.
Both anti-patterns come from the same place: treating the naming choice as decoration instead of a structural commitment. The structural commitment is what matters.
What survives across both styles
Whatever you pick, the rules below hold:
- The application layer never imports from the framework. No Eloquent models, no Symfony attributes, no Laravel facades. The application orchestrates the domain through ports.
- The domain knows nothing about the application layer. Entities and value objects sit one ring further in and stay there.
- One command class per verb, no matter whether the verb lives in its own UseCase or as a method on an ApplicationService. The command is the contract; the handler is the implementation.
- Controllers and CLI commands and queue workers are inbound adapters. They translate transport-level input into a command and call the application. They do not contain business logic.
- Ports live with the application layer (or the domain), not with the adapters that implement them. The application names the shape of what it needs; infrastructure conforms.
If those five rules hold, you can swap an OrderApplicationService for three UseCase classes in an afternoon without touching the domain, the controllers, or the tests beyond their setup blocks. The two styles are swap-compatible inside the same architecture. They are not swap-compatible in everyday code review. That is the conversation worth having on your team this week.
If this was useful
The “where does this code go” question is half of what makes hexagonal and clean architecture feel hard in PHP, and naming conventions are the other half. Decoupled PHP walks the full project shape (domain, ports, application, adapters) with both architectures side by side, in PHP 8.3, with a public examples repo for each chapter. If your team has been arguing about service-versus-use-case for longer than is healthy, the book picks a side and shows the trade.
Available on Kindle, Paperback, and Hardcover. English, German, and Japanese editions out now — Portuguese and Spanish coming soon.
