Size: a a a

Software Design/Architecture/Zen

2021 January 15

SF

Segmentation Fault in Software Design/Architecture/Zen
Roman
Значит ССЗБ?)
Нет)
источник

R

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

R

Roman in Software Design/Architecture/Zen
А, есть ещё битбакет, да. Там даже cicd есть
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Roman
Я могу представить, что там какой-нибудь gogs или что ещё похлеще, но CI/CD же
У нас atlassian стек
источник

R

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

HH

Human Human in Software Design/Architecture/Zen
А что для ci/cd нужно непосредственно что-то из этого набора?)
источник

HH

Human Human in Software Design/Architecture/Zen
дженкинсы есть всякие же
источник

R

Roman in Software Design/Architecture/Zen
Поднимать всякие дженкинсы или написать один yaml файл)
источник

R

Roman in Software Design/Architecture/Zen
Конечно можно всё самому, но зачем
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Human Human
А что для ci/cd нужно непосредственно что-то из этого набора?)
Ну гитхаб имеет встроенную поддержку, раньше не было.
Битбакет не имеет, для этого у них есть отдельный продукт.
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Human Human
дженкинсы есть всякие же
Ну вот много удобнее если есть экосистема таких сервисов.
источник

MG

Max Grom in Software Design/Architecture/Zen
Human Human
Обычно просто есть “что-то” и мы ищем глазами класс с суффиксом Factory и понимаем что оно это создает. А так нужно читать все названия и разбираться в терминах, чтобы понять что вот в А логика создания Б
Может это потому что у вас “DDD” без словаря и без поддержки бизнеса?
источник

SF

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

SB

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

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

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

SF

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

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

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

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Segmentation Fault
"У вас" - это где? Я же спрашиваю как правильно.

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

SF

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

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

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

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

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Segmentation Fault
> Можете привести пример когда и зачем вам нужны эти доменные или апликашн сервисы?

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

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

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

SF

Segmentation Fault in Software Design/Architecture/Zen
Sergei Baikin
помоему они обе не так чтобы полностьбю бизнес операции

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

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

SB

Sergei Baikin in Software Design/Architecture/Zen
Segmentation Fault
> Вторая не меняет стейт чисто себе чтение

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

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