В продолжение вчерашнего диалога. На счет сервисов: резюмируя можно сказать, что доменный сервис должен работать исключительно с сущностьями предметной области, а не с идентичностью (идентификаторами), не зависить от состояния и быть максимально маленьким. Сервисы приложения наоборот, должны инкапсулировать доменную логику, и координировать действия сервисов связывая с сотояними. Насколько это так?

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

Положите части этого алгоритма рядом с данными причем не завязваясь на сущность ибо это просто чтение. Ваш кальулятор вообще не должен ничего знать о сущностях или состовных частях
просто позвольте ему динамически брать все доступные части алгоритма почитанные там внутри модулей к которым ваши сущности относятся и складывать их вместе. Ему будет глубоко фиолетово откуда дыные и сколько разных частей учавствуют в расчетах. Оно не меняет даные оно просто отдает цену на отображение. Нечего общего с бизнес логикой и ее констрейнтами не имеет.

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

Все верно, эта логика должна быть в доменных сервисах.

а почему не в доменных агрегатах? зачем вам отделять логику от данных?

а почему у вас логика отделена от состояния?
почем бы не хранить логику вместе с состоянием?
Вроде как это и есть основной смысл всех тесируемых и поддерживаемых штук

Зачем вам писать какието доменные апликационные сервисы если есть аггрегат\модель в который можно и состояние и логику иметь?

Можете привести пример когда и зачем вам нужны эти доменные или апликашн сервисы?

Потому я лично считаю доменные сервисы довольно узкой и опциональной* штукой

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

Получается, что если таких правил нет, скажем у меня обычный CRUD, то домен может быть в принципе пустым, либо ограничется моделями?

Их роль - убрать куда-то логику из application сервисов в случаях когда агрегаты не могут брать это на себя

Да, и в этом случае стоит "пустые слои" убирать

тоесть идея что кто то там ходит по всем агррегатам системы потрашит их и делаем что ему надо?

Я все таки больше в этом случае склоняюсь к Engine Pattern от уди когда оно не ходит и не знат о наших кишках

Я тоже больше к этому склоняюсь но часто логика слишком простая что бы это тянуть

Sagas для бедных?)

ну когда слишком простая в собираю специфические ивенты внутри калькулятора и храню там его персональный стейт.

Таким образом оно не имеет прямых заисимостей от половины системы и я вижу и контролирую данные для расчетов.

Но это для меня обычная модель аггрегат получается а не доменный сервис

Я в вашем примере не понимаю как вы избегаете протекания стейта аггрегатов котрые вы используете наружу

Саги все ж про принятие решений в контексте колаборативного домена. За счёт ограничения что ты сагу не можешь сам дёрнуть (только кинув сообщение в шину) оно тебе какие-то гарантии даёт. Достаточно часто у тебя нет колаборации и есть необходимость потрогать несколько агрегатов.

Апликейшен левел сервисы это юзкейсы в терминах луковой архитектуры. Или grasp controller

Но даже если ты сам дергаешь, тебе ж надо и евеншуал между агрегатами, и коппенсационные действия в случае чего. Не совсем понятно ограничение, что сагу можно стартовать только сообщением в шине. В чем принципиальная разница?