А почему не имеет? Я хочу разобраться в теории

Ну ты сам понимаешь зачем оно нужно разделение? Почему именно 2 типа сервисов есть, а не 3 или 500?

Вообще начало книги говорит про моделирование предметной области. Про единый язык и что круто отделить бизнес модель от всех остальных деталей. По сути дальше автор приводит один из возможных вариантов того, как отделить эту модель. Те не так важно, что делает app serivce и что это такое. Автор просто говорит про важность изоляции сложной бизнес-модели.

Чаще всего если в конкретном месте бизнес логики мало, то и выделять модель не особо нужно.

Но если взять менее конкретно. То это проблема разделения отвественностей. Типа сделать перевод денег и отправить email c уведомлением об этом - это разные штуки.
Если интересна эта тема, лучше почитать например чистую архитектуру дяди Боба

Мне кажется, я не могу определить где грань бизнес логики, а где нет.

> Автор просто говорит про важность изоляции сложной бизнес-модели.

Разумеется, но где проходит грань? Поиск заказа - бизнес логика, безусловна. Она затрагивает репозиторий и сущность. Вызов репозитория - это домен? Мне кажется, что да. Но где-то пишут, что в домене нельзя работать с примитивами (айдишником например). Тогда это слой приложения. И тут я потерялся..

Вот поэтому и не стоит воспринимать эти правила так однозначно. Вообще все бизнес-логика для своего контекста. Отправить уведомление на почту - бизнес-логика для контекста уведомлений. Это и есть разделение отвественностей.

для начала давай договоримся что если есть какое-то понятие (например доменный сервис, сервис уровня приложения) это не значит что тебе надо его вводить в рамках своей реализации. Все эти штуки - это опции. Твоя цель выбрать минимум а не все. То есть вполне возможно что у тебя нет кейсов для доменных сервисов и это нормально.

Затем... разницу надо уяснить не между доменными сервисами и сервисами уровня приложения а между "приложением" и "доменом". Домен - это твоя бизнес логика. Правила и ограничения. Приложение тут - это "оболочка" - считай интерфейс к домену. Может быть CLI, может быть HTTP. То есть это тот слой адаптеров который защищает твой домен от холодного и жестокого внешнего мира.

Дальше про "сервисы". Это такие вот "функции" которые не помещаются в рамках какого-то объекта. Клей между объектами. У сервисов нет своего стэйта, им остается лишь брать данные которые приходят на вход, какие-то еще данные и перенаправлять их другим.

Типичный пример сервиса уровня приложения это какой-нибудь HTTP контроллер или там консюмер в очереди. Чаще всего у тебя будут именно сервисы уровня приложения просто потому что без них сложно склеивать и перенаправлять операции.

Приложение задает границу бизнес операции. Мол что включает в себя какой-то http запрос. Мол вот захотелось тебе в рамках одного http запроса опубликовать сразу несколько айтемов в каталоге. В этом случае сервис уровня приложения дернет паблиш у нескольких айтемов.

Бизнес операция может быть представлена несколькими логическими транзакциями. Чаще всего одна логическая транзакция это вызов метода у доменного объекта который изменит его стэйт. Но есть ситуации когда тебе выгодно раздробить стэйт на несколько маленьких объектов и есть разные комбинации как с этими объектами работать. Эти комбинации можно объединить в доменный сервис который бует своего рода фасадом что бы жестко задать приложению что можно делать. Мол это бизнес-ограничение.

Есть еще забавные примеры с сервисами которые представляют собой какие-нибудь стратегии вычислений и должны использоваться только внутри домена (всякие вычисления скидок которые ты передаешь на вход объекту который владеет стэйтом).

Главное в чем надо разобраться - нафига вводится разделение на домен и приложения. Лучше всего про это можно почитать Алистера Кокберна и его архитектуру портов и адаптеров. Главное не читай булшит где еще всякие command bus-ы туда пихают. Ну и причем тут anti corruption layer (не причем просто как пример еще одного выделения ответственности).

Большое спасибо. Я уже понял что до конца не понимаю где бизнес логика, а где нет)

> не могу определить где грань бизнес логики, а где нет
Это не столь критично. Полагаю, у вас нет особо источника бизнес-требований или он не работает с вами по DDD, то подобные кейсы - реально и нормально

тут важно понимать что разделение на такие вот простые категории обычно приводит к мерзским пограничным кейсам где "нипонятно". потому в целом для схематичного описания идей это все подходит хорошо (в большинстве случаев ты это сможешь явно отличить) но в целом зацикливаться на этом не стоит.

Если ты будешь выделять зоны ответственности (тот самый SRP из SOLID) и будешь пытаться держать объекты относительно маленькими (иначе сложно соблюдать SRP) то все это разделение будет складываться само собой.

Могу тебе только порекомендовать больше фапать на "где граница разных бизнес логик" нежели где границы слоев.

Требования задает ПО словами, зачастую описывает сценарии даже упомниая такие фразы: "взять данные оттуда", "сохранить там-то", "отправить уведомление" и тд. Мы с ним разумеется использум одинаковые термины. Но реализации прячем за интерфейсами. Наверное поэтому сложно понять что именно бизнесс логика, потому что кажется, что она повсюду.

у Вернона было понятие true invariant. А когда продукт говорит тебе "что откуда брать и что куда сохранять" то это как минимум странно

Почитаю, спасибо

Ну он говорит это "с потолка", конечно, очень по-верхам

модель строят по тому как всем этим пользуются а не из чего оно состоит или хранится. Я к этому больше. Иначе легко попасть в ситуацию что у тебя система состоит из жирных сущностей аля "пользователь", "заказ", "клиент". Потом когда вдруг появляется нужда bounded context дробить (например когда надо разбить продукт на несколько команд разработки) ты будешь грустить

Я ж потому и говорю, не парьтесь, что не всё идеально. PO использует это потому что хочет лучше детализирвоать для вас что к чему. Это встречается очень часто и очень мало PO умеют или имеют возможность в вычленение бизнес-процесса, способность его осознать/описать/презентовать и дать задачи в формате as-is -> to-be для этих изменений не пытаясь навязать вам реализацию

Вот я сейчас примерно так и делаю, пытаюсь в DDD, но выходит противоречиво. У меня есть домен, состоящий из сервисов, сущностей (+ VO) и там же интерфейсы репозиториев. А есть сервисы приложений (для аутентификации, рассылок и еще чего-то). И непонятно куда поместить интерфейсы репозиториев необходимые для сервисов приложений. Реализация лежит в инфраструктуре...