Телеграмм чат группы oop

Size: a a a

Software Design/Architecture/Zen

2146 membersпожаловаться на группу

2021 July 26

Dimitry Polonskiy in Software Design/Architecture/Zen

1. ChangeProductPrice(price)

2. Обычный репозитрий

3. Это псевдокод

источник

15:45пожаловаться #1

Nikita Fedorov in Software Design/Architecture/Zen

ну просто если Product это агрегат и

ChangeProductPrice(...) {
return new Product(...);
}

то это бред
> если там

ChangeProductPrice(...) {
return clone(...);
}

то это уже менее бред, но всё ещё бред

источник

15:47пожаловаться #2

Dimitry Polonskiy in Software Design/Architecture/Zen

Неважно, что там под копотом.
Как сам факт, что измененный стейт это новый объект.

источник

15:50пожаловаться #3

Nikita Fedorov in Software Design/Architecture/Zen

банально потому что за построение частично отвечает орм и делать постоянно new Product из прокси, который не будет проксей это прям грязно

источник

15:52пожаловаться #4

Aleh Kashnikau in Software Design/Architecture/Zen

Обмажутся своими проксями

источник

15:56пожаловаться #5

Nikita Fedorov in Software Design/Architecture/Zen

это нормально если иммутабельность это просто деталь реализации, но в таком случае она должна быть в инфраструктуре, по этому я и спросил что внутри.
Если иммутабельность это предметное решение, т.е. когда вам менеджер говорит что надо создать продукт с новой ценой, а не изменить цену, то это тоже норм. Или скажем есть несколько(N>2) версий с которыми вы одновременно работаете.

источник

15:57пожаловаться #6

Nikita Fedorov in Software Design/Architecture/Zen

обмажутся своей кодогенерацией 🙃

источник

16:05пожаловаться #7

Sergey Protko in Software Design/Architecture/Zen

Бизнесу это знать не нужно, нужно учиться с ним общаться в терминах "что если это вот правило на секунду будет нарушено"

источник

16:26пожаловаться #8

Sergey Protko in Software Design/Architecture/Zen

Для этого у тебя должны быть юзкейсы, правила, описан воркфлоу пользователей и и д

источник

16:28пожаловаться #9

Sergey Protko in Software Design/Architecture/Zen

Бизнес тебе увы не разделит систему

источник

16:28пожаловаться #10

Human Human in Software Design/Architecture/Zen

А как иммутабельность данных в коде связана с агрегатами?

источник

16:32пожаловаться #11

Dimitry Polonskiy in Software Design/Architecture/Zen

Вопрос был про детали реализации

источник

16:33пожаловаться #12

Dimitry Polonskiy in Software Design/Architecture/Zen

Принято.
Спасибо.

источник

16:33пожаловаться #13

Sergey Protko in Software Design/Architecture/Zen

Если данные не меняются у тебя нет стэйта, соответственно нет и инвариантов, соответственно и агрегаты не нужны. Но только это скорее всего немного другой уровень. Стэйт всеравно есть, даже если у тебя там append only структуры всеравно партиции нужны

источник

16:34пожаловаться #14

Human Human in Software Design/Architecture/Zen

Да, но это немного разные вещи - изменение агрегата и изменение объекта агрегата в коде. Типа возвращать ли новый объект или менять старый вопрос подхода. Агрегат все равно будет изменен

источник

16:36пожаловаться #15

Sergey Protko in Software Design/Architecture/Zen

Все так

источник

16:38пожаловаться #16

Human Human in Software Design/Architecture/Zen

Крч вопрос инфраструктуры которую юзаешь. В Java не удобно например, в Kotlin уже более менее

источник

16:40пожаловаться #17

Aleh Kashnikau in Software Design/Architecture/Zen

append only в коде может быть организован как возврат из метода того, что нужно добавить. Грубо говоря aggregateAction :: AggregateState -> [Event]

источник

16:41пожаловаться #18

Human Human in Software Design/Architecture/Zen

Haskell💪💪 😆

источник

16:43пожаловаться #19

Nikita Fedorov in Software Design/Architecture/Zen

если дефолтный вариант это:
agg = proxy(agg1) | agg ext AggRoot
agg.a()
agg.b()
agg.events // [a,b]
agg1.events // no
что собственно и делается, зачем может быть нужно делать это для каждого метода отдельно? в чем прикол

источник

16:47пожаловаться #20