Чим доменний сервіс відрізняється від сервісу застосунку?

Обидва - «сервіси», але на різних рівнях і з різною відповідальністю.

Доменний сервіс - бізнес-логіка, що не належить природно жодній сутності чи об'єкту-значенню. Зазвичай - операція, що охоплює кілька агрегатів чи потребує зовнішніх правил:

final class TransferPolicy
{
    public function transfer(Account $from, Account $to, Money $amount): void
    {
        if ($from->isFrozen() || $to->isFrozen()) {
            throw new AccountFrozen();
        }

        $from->withdraw($amount);
        $to->deposit($amount);
    }
}

Ознаки доменного сервісу:

• назва з єдиної мови (PricingPolicy, TransferPolicy, ShippingCostCalculator);
• без інфраструктури: не знає про HTTP, базу, черги, пошту;
• без стану - лише операції над доменними об'єктами.

Сервіс застосунку (application service, use case) - координує виконання сценарію: отримує вхідні дані, завантажує агрегати, викликає доменну логіку, зберігає результат, запускає побічні ефекти.

final class TransferMoney
{
    public function __construct(
        private AccountRepository $accounts,
        private TransferPolicy $policy,
    ) {}

    public function handle(int $fromId, int $toId, Money $amount): void
    {
        DB::transaction(function () use ($fromId, $toId, $amount) {
            $from = $this->accounts->lockForUpdate($fromId);
            $to = $this->accounts->lockForUpdate($toId);

            $this->policy->transfer($from, $to, $amount);

            $this->accounts->save($from);
            $this->accounts->save($to);
        });

        MoneyTransferred::dispatch($fromId, $toId, $amount);
    }
}

Ознаки сервісу застосунку:

• тонкий: жодних бізнес-правил - лише оркестрація;
• знає про транзакції, авторизацію, події, черги;
• відповідає одному сценарію використання.

Чому розділення корисне: бізнес-правила (доменний сервіс, агрегати) тестуються без бази й фреймворку; сценарій (сервіс застосунку) - інтеграційними тестами. Правила не змішуються з технічними деталями.

У Laravel роль сервісу застосунку часто виконують actions (app/Actions/TransferMoney.php), job-класи чи тонкі контролери з Form Request. Типова помилка - «сервіс застосунку», в якому зосереджено всю бізнес-логіку, а моделі лишаються анемічними: тоді це вже не DDD, а транзакційний сценарій.

Докладніше в документації: Microsoft: проєктування DDD-орієнтованого мікросервісу