Size: a a a

Software Design/Architecture/Zen

2021 January 15

SP

Sergey Protko in Software Design/Architecture/Zen
Segmentation Fault
В продолжение вчерашнего диалога. На счет сервисов: резюмируя можно сказать, что доменный сервис должен работать исключительно с сущностьями предметной области, а не с идентичностью (идентификаторами), не зависить от состояния и быть максимально маленьким. Сервисы приложения наоборот, должны инкапсулировать доменную логику, и координировать действия сервисов связывая с сотояними. Насколько это так?
В апликейшен сервисах не должно быть логики. Ну или ее должно быть настолько мало что бы не возникало желания юнитами закрывать (один позитивный приемочных тест все покроет)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergei Baikin
У вас тогда это все дело протекает
Если может читать один то могут и остальные
А значит кто то начнет принимать бизнес решения на основе данных из вне транзакций и получится шляпа с неконсистеностью.

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

> Если может читать один то могут и остальные
Кто один и то читать?

> А значит кто то начнет принимать бизнес решения на основе данных из вне транзакций
Какая еще транзакция?

Сори, но мне кажется вы вообще не понимаете смысл моего вопроса
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
В апликейшен сервисах не должно быть логики. Ну или ее должно быть настолько мало что бы не возникало желания юнитами закрывать (один позитивный приемочных тест все покроет)
Все верно, эта логика должна быть в доменных сервисах.
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Segmentation Fault
Все верно, эта логика должна быть в доменных сервисах.
а почему не в доменных агрегатах? зачем вам отделять логику от данных?
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergei Baikin
а почему не в доменных агрегатах? зачем вам отделять логику от данных?
Что значит "логика от данных"?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Sergei Baikin
а почему у вас логика отделена от состояния?
почем бы не хранить логику вместе с состоянием?
Вроде как это и есть основной смысл всех тесируемых и поддерживаемых штук

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

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

SP

Sergey Protko in Software Design/Architecture/Zen
Потому я лично считаю доменные сервисы довольно узкой и опциональной* штукой
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Их роль - убрать куда-то логику из application сервисов в случаях когда агрегаты не могут брать это на себя
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
Потому я лично считаю доменные сервисы довольно узкой и опциональной* штукой
Получается, что если таких правил нет, скажем у меня обычный CRUD, то домен может быть в принципе пустым, либо ограничется моделями?
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Sergey Protko
В очень редких случаях есть логика которая не привязана к состоянию. Какой нибудь калькулятор комиссий где можно разные стратегии подставлять. По хорошему мутировать стэйт им тоже нельзя
тоесть идея что кто то там ходит по всем агррегатам системы потрашит их и делаем что ему надо?

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

SP

Sergey Protko in Software Design/Architecture/Zen
Segmentation Fault
Получается, что если таких правил нет, скажем у меня обычный CRUD, то домен может быть в принципе пустым, либо ограничется моделями?
Да, и в этом случае стоит "пустые слои" убирать
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Sergey Protko
Их роль - убрать куда-то логику из application сервисов в случаях когда агрегаты не могут брать это на себя
Sagas для бедных?)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergey Protko
Да, и в этом случае стоит "пустые слои" убирать
Тогда я правильно все понял, спасибо
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Sergei Baikin
тоесть идея что кто то там ходит по всем агррегатам системы потрашит их и делаем что ему надо?

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Sergey Protko
Я тоже больше к этому склоняюсь но часто логика слишком простая что бы это тянуть
ну когда слишком простая в собираю специфические ивенты внутри калькулятора и храню там его персональный стейт.

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

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

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

SP

Sergey Protko in Software Design/Architecture/Zen
Dmitriy Tkachenko
Sagas для бедных?)
Саги все ж про принятие решений в контексте колаборативного домена. За счёт ограничения что ты сагу не можешь сам дёрнуть (только кинув сообщение в шину) оно тебе какие-то гарантии даёт. Достаточно часто у тебя нет колаборации и есть необходимость потрогать несколько агрегатов.

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

SP

Sergey Protko in Software Design/Architecture/Zen
Sergei Baikin
ну когда слишком простая в собираю специфические ивенты внутри калькулятора и храню там его персональный стейт.

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

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

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

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Sergey Protko
Саги все ж про принятие решений в контексте колаборативного домена. За счёт ограничения что ты сагу не можешь сам дёрнуть (только кинув сообщение в шину) оно тебе какие-то гарантии даёт. Достаточно часто у тебя нет колаборации и есть необходимость потрогать несколько агрегатов.

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

SP

Sergey Protko in Software Design/Architecture/Zen
Ещё аналогия - если брать functional core imperative shell то апликейшен левел сервисы это тот самый императивный шел без логики но с сайд эффектами. А доменные сервисы будут чистыми функциями
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Dmitriy Tkachenko
Но даже если ты сам дергаешь, тебе ж надо и евеншуал между агрегатами, и коппенсационные действия в случае чего. Не совсем понятно ограничение, что сагу можно стартовать только сообщением в шине. В чем принципиальная разница?
Если нет конкуренции за агрегаты или вероятность этого низкая то не надо усложнять все сагами
источник