AL
я говорю про модель, а не реализацию.
Size: a a a
2021 July 26
AD
модель не материальна
AD
модель это идея
AL
да, но отражает материальные вещи
AL
а так, я спорить не собираюсь. я высказал то как я объяснял бизнесу и как мы находили Общий Язык.
И когда на очередной итерации мне говорили, что у "накладных появляется новая форма" я сразу понимал куда мне лезть в код и что менять.
И когда на очередной итерации мне говорили, что у "накладных появляется новая форма" я сразу понимал куда мне лезть в код и что менять.
HH
А идея откуда рождается?) правильно- из бизнеса
AD
по барабану. Важно что это информация об обьекте а не сам обьект
ВУ
Претензия к слову "материальный", видимо. У нас агрегаты — это, в частности, "опрос", "прохождение опроса" и т.д. Всё это нематериальные штуки, но там сосредоточены важные инварианты.
AL
по барабану. Важно что бы бизнес и программисты друг-друга понимали.
DP
Также возник вопрос.
Что касается агрегатов выраженных в виде иммутабельных объектов в коде. (Изменение чейнджа происходит созданием нового)
Как вы к этому относитесь? В чем плюсы? И в чем подводные?
Что касается агрегатов выраженных в виде иммутабельных объектов в коде. (Изменение чейнджа происходит созданием нового)
Как вы к этому относитесь? В чем плюсы? И в чем подводные?
ВУ
Ну вообще странно, если состояние никогда не меняется после создания. Потому что сама идея агрегата — транзакционная граница вокруг некоторого процесса, некоторых изменений. Если объект иммутабельный, его проще напрямую в хранилище записать с id-шкой и всё. Как таковая агрегатность и прочие усложнения тут не нужны.
Другое дело, когда в процессе взаимодействия агрегат становится неизменямым в соответствии с логикой (archived/locked/unavailable/...). Тогда можно его попросить создать для тебя новый инстанс, не мутируя состояние.
Другое дело, когда в процессе взаимодействия агрегат становится неизменямым в соответствии с логикой (archived/locked/unavailable/...). Тогда можно его попросить создать для тебя новый инстанс, не мутируя состояние.
DP
Ну фактические идея тут была заложена такая:
https://youtu.be/O89-zG84QK4
Но я бы хотел начать это выпиливать и вернуться к уже мутабельным вещам.
А то работа с агрегатами превращается на работу с VO, что если нужен новый VO замени старый новым.
https://youtu.be/O89-zG84QK4
Но я бы хотел начать это выпиливать и вернуться к уже мутабельным вещам.
А то работа с агрегатами превращается на работу с VO, что если нужен новый VO замени старый новым.
AK
что имеется ввиду, создание новой записи с версией?
DP
var product = GetProductById()
var product = product.ChangeProductPrice()
Repository.Save(product);
var product = product.ChangeProductPrice()
Repository.Save(product);
DP
Ну версии как таковой нет, но создается уже изменивший свой стейт объект - агрегат.
И сохраняется в базу
И сохраняется в базу
AK
ага, понятно. Зависит от развитости в языке методов работы с имутабельностью и соответственно ограничений вашей orm
DP
Не могу обьяснить, как так получилось и почему именно такой способ изменения стейта был выбран, но я считаю это очень неудобным и создает много аллокаций.
DP
Ну тут я достаточно свободен.
Это C#.
Если бы система была бы написана на фп и к примеру на F#, то бы понял почему так.
Это C#.
Если бы система была бы написана на фп и к примеру на F#, то бы понял почему так.
AK
это накладывает неплохие ограничения(мол надо явно передать ссылку на агергат и нельзя неявно поменять еще другие агрегаты) и может быть удобно для типизации(фантомные типы какие)
NF
покажите метод ChangeProductPrice
и эм Repository это this.repository а не статический метод да?
и эм Repository это this.repository а не статический метод да?