Size: a a a

Software Design/Architecture/Zen

2021 July 02

SP

Sergey Protko in Software Design/Architecture/Zen
"под зова" - ?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это оч сложная концепция - многогранная. Так что сложно.

Можешь начать с functional core imperative shell каких публикаций.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
User - домен. Интерфейс резпозитоия изеров - домен (наверное). А координация - app. Кто-то говорит, что это не бизнес процесс, поскольку денег не приносит. А другие считают, что это домен, потому что без этого денег не перенесёт в принципе… вот сиди и думай…
источник

SP

Sergey Protko in Software Design/Architecture/Zen
давай называть вещи своими именами:

- User это свалка даных которая сочитает в себе и операции для изменения стэйта и для UI.
- интерфейс репозитория юзеров может быть доменом до тех пор пока там то что должно быть в репозитории. Как пример - подумай куда ты запихнешь сложный сводный репорт "все юзеры которые покупали красные майки за последний квартал"
- app это координация да.

Основная проблема - попытка разделить все на два слоя. Реальность увы сурова и сложнее
источник

SP

Sergey Protko in Software Design/Architecture/Zen
источник

SP

Sergey Protko in Software Design/Architecture/Zen
если мысленно представить что у нас вместо application есть domain то одна из граней шестигранника у тебя будет use cases какие например. Может так будет проще
источник

SP

Sergey Protko in Software Design/Architecture/Zen
главное что бы один такой "модуль" был модулем а не "вся система такой вот кружок и вот application это просто свалка с высокой связанностью"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
какой смысл в слоях если реальная проблема обычно в всязях и зависимостях внутри domain :)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Ну фактически именно у нас ещё есть слой инфраструктуры с реализацией репозиториев и слой с представлением (http, cli и тп). С этими ясно, с двумя о которых говорим обычно сумятится.
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
UseCase - это и есть app в моей терминологии
источник

k

knopkod4v in Software Design/Architecture/Zen
надо учиться разбивать стейт например. Не шарить данные, которые меняются или выдают какие-то детали
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну вот условно - допустим у тебя стоит задача вывести список пользователей. ты для этого будешь делать юзкейс?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
или для этого будет что-то еще
источник

SP

Sergey Protko in Software Design/Architecture/Zen
я только хочу отметить что это пиздец сложно)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Я бы сделал. Этот юзкейс будет требовать интерфейс репозитория юзеров и логгер, например. А вызывать его будет, скажем, http представление
источник

k

knopkod4v in Software Design/Architecture/Zen
это настолько сложно, что люди часто не верят, что это в принципе возможно
источник

SP

Sergey Protko in Software Design/Architecture/Zen
окей, допустим. Теперь следующее - "надо список юзеров и информация сколько каждый покупал за последний месяц". Тоже юзкейс? Один репозиторий? два? Отдельный сервис который будет делать джойны?
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
Другой юзкейс. В зависимости 2 репозитория - Юзеров (но другой метод используется) и Покупок, ну и логгер :)
источник

SF

Segmentation Fault in Software Design/Architecture/Zen
С репозиториями наверное намудрил. Может и одного хватит...
источник