В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Software Design/Architecture/Zen

2184 membersпожаловаться на группу
2021 November 24

k

knopkod4v in Software Design/Architecture/Zen
мне кажется, что в том, что один и тот же стейт юзается и для чтения и для записи нет ничего страшного.
Какие причины не юзать табличку, в которой агрегат для чтения?
Вот если 2 разных приложения пишет в 1 стейт, то это может быть большой проблемой
Есть конечно всякие ивент-сурсинги , но если мы говорим о небольших приложениях, где не надо вот этот весь оверинжениринг, то я бы так и сделал
источник
22:36пожаловаться#1

N

Nikita in Software Design/Architecture/Zen
Есть пример? Солиды и ооп очень уж "расплывчастые" понятия
источник
22:36пожаловаться#2

A

Alexander in Software Design/Architecture/Zen
Ну я обычно хз что клиенту захочется дальше. А обычно ему хочется еще и еще. Если делать анемичную модель изначально, то на определенном этапе придется предметную область все равно выделять
источник
22:36пожаловаться#3

VL

Vanya Leyn in Software Design/Architecture/Zen
а в чем расплывчивость?
источник
22:37пожаловаться#4

A

Alexander in Software Design/Architecture/Zen
Табличек может быть несколько. Логики в агрегатах тоже может быть неоправданно много для запроса.

Ну это я так думаю. Пока что коммерческого опыта с этим мало
источник
22:38пожаловаться#5

k

knopkod4v in Software Design/Architecture/Zen
Несколько табличек... В чём проблема? Юзай джоины
Не понял при чём тут сколько логики в агрегатах 🤔
источник
22:40пожаловаться#6

SM

Sergey Milegov in Software Design/Architecture/Zen
Было время люди не знали про эти ваши ддд, и делали проекты и большие и маленькие. Если хочете делать всё везде по ддд, то вэлкам. У эванса в первой главе вроде написано, кому оно не надо и почему.
источник
22:40пожаловаться#7

N

Nikita in Software Design/Architecture/Zen
Кмк, если плотно применить солиды и граспы, то в какой то мере неоснознанно получится та же чистая архитектура, и мы возвращаемся к изначальному вопросу
источник
22:42пожаловаться#8

AB

Aleksandr Bespalov in Software Design/Architecture/Zen
Если плотно принципы ООП применять, то, внезапно, код тоже будет чистый.
источник
22:43пожаловаться#9

VL

Vanya Leyn in Software Design/Architecture/Zen
соблюдение принципов здорового человека это не совсем СКРС с ивентсорсой и агрегатом, разве нет?
источник
22:43пожаловаться#10

N

Nikita in Software Design/Architecture/Zen
При чем тут cqrs и ивентсорса?))
источник
22:44пожаловаться#11

VL

Vanya Leyn in Software Design/Architecture/Zen
не так тебя прочитал, услышал вопрос о том как жить без оверхедов типа выше)
короч, соблюдение здоровых принципов это вещь совсем не тяжелая, а скорее удобная при еволюционировании проекта, так же будет намного удобнее и проще тестировать
по поводу прихода к чистой архитектуре, а это разве сложно и тяжело? будет проще писать новый код относительно бигболлофмада и в разы приятнее тестировать
источник
22:48пожаловаться#12

A

Alexander in Software Design/Architecture/Zen
Я про то, что зачем делать большой запрос на несколько таблиц, собирать агрегат с логикой, если никаких операций не предвидится и данные мб не все нужны. В итоге получается, что агрегаты для чтения избыточны. Ну это я так вижу и оправдываю применение CQRS, но это не точно, еще не копал в эту сторону
источник
22:49пожаловаться#13

k

knopkod4v in Software Design/Architecture/Zen
маленькое приложение. Какая там избыточность и проблемы с производительностью?
Читай только те данные, которые нужны. SQL позволяет выбирать только то, что надо
источник
22:51пожаловаться#14

VL

Vanya Leyn in Software Design/Architecture/Zen
можно агрегат собирать частями а не за раз
источник
22:51пожаловаться#15

A

Alexander in Software Design/Architecture/Zen
Типа lazy loading?
источник
22:51пожаловаться#16

NF

Nikita Fedorov in Software Design/Architecture/Zen
они и не для чтения, для чтения query factory
источник
22:51пожаловаться#17

k

knopkod4v in Software Design/Architecture/Zen
на самом деле тут сразу вопрос возникает "А что это у тебя там за такой огромный агрегат?".
Ну и когда ты апдейтишь его - ты юзаешь какой-то репозиторий, где метод getById, а когда на ui отдаёшь - собирай себе при помощи SQL как хочется
источник
22:52пожаловаться#18

VL

Vanya Leyn in Software Design/Architecture/Zen
идея похожа но это отдельный вариант https://enterprisecraftsmanship.com/posts/domain-model-purity-lazy-loading/

я скорее про то что у тебя аггрегат состоит из 3 ентитей
тебе над ток 1
так создай пустой агрегат, вкинь туда ентитю с бд и усе (или создай ток с 1)
если надо 2, вкинь 2
Enterprise Craftsmanship
Domain model purity and lazy loading
I’m continuing the topic of domain model purity. Last time, we talked about domain model purity in the context of getting the current date and time. Today, we’ll discuss it with regards to lazy loading.
источник
22:52пожаловаться#19

A

Alexander in Software Design/Architecture/Zen
спасибо, посмотрю
источник
22:53пожаловаться#20