Нет)

Я могу представить, что там какой-нибудь gogs или что ещё похлеще, но CI/CD же

А, есть ещё битбакет, да. Там даже cicd есть

У нас atlassian стек

А, ну кстати, когда был битбакет, я чекаутил ветку МРа локально и смотрел её в IDE:)

А что для ci/cd нужно непосредственно что-то из этого набора?)

дженкинсы есть всякие же

Поднимать всякие дженкинсы или написать один yaml файл)

Конечно можно всё самому, но зачем

Ну гитхаб имеет встроенную поддержку, раньше не было.
Битбакет не имеет, для этого у них есть отдельный продукт.

Ну вот много удобнее если есть экосистема таких сервисов.

Может это потому что у вас “DDD” без словаря и без поддержки бизнеса?

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

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

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

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

"У вас" - это где? Я же спрашиваю как правильно.

По идее доменный сервис не должен быть stateless, а если он содержит репозиторий (интрейфейс), то получается, что не stateless. И всё что связано именно с сотоянием надо выносить в службы уровня приложения. И мой вопрос - так ли это?

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

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

Мне они пока не очень нужны. Я в теории хочу разобраться.
Возьмем пример. Нужно завести нового пользователя в системе. Это persistance операция. Принимаем набор данных и сохраняем в репозитории. Это разве бизнес логика? Наверное нет.

А расчитать стоимость товара с учетом скидок и прочих объектов - это бизнес операция.
Я вижу это так.

помоему они обе не так чтобы полностьбю бизнес операции

Первая не имеет логики
Вторая не меняет стейт чисто себе чтение

> Вторая не меняет стейт чисто себе чтение

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

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

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