(может быть я неправильно употребил термин агрегат перестаёт быть агрегатом если его куда-то смапили? или если нарисовали на бумажке) нет, не доменная. прилетает DTO из фронтенда и в нём лежит информация для обновления агрегата, структурно его повторяющая

с фронтенда прилетает не агрегат, а дто которая может чем-то напоминать ваш объект, но вообще совершенно необязательно, эту дто даете вашему агрегату в какой-то конкретный метод(зависит от того, что за действие выполняется, например updateProfile, bookItem и т.д.), он уже сам думает че и как ему обновить

зачем присылать id внутренних структур неясно

или вообще зачем присылать с фронта то, что не может изменится

э… а как идентифицировать сущности для обновления, если не знать их id? есть папка с пронумерованными листами. я отправил папку юзеру, он на некоторых написал, а некоторые выбросил и отал мне папку обратно. как без id листа обновить состояние оного?

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

не понимаю задачи, не могу советовать решение. Если вы уже знаете агрегат, то дальше все достаточно просто. Если у вас там какие-то мутабельные списки в агрегате, то вероятно стоит разделить агрегат

мм… выкинуть — вариант, наверное. но мне ещё нужно сохранить состояние в базе. и чтобы выкинуть нужно будет вначале вычистить всё из базы по связям, а потом сохранить новую папку, получив побочкой ещё и новый автоинкремент ключей. а юзер всего лишь поменял тайтл в одном листе а у папок несколько уровней вложенности возможно, вместо DTO с конечным состоянием папки более красиво сделать Event Sourcing на фронте и кормить агрегат изменениями, но это немного времязатратно в данный момент поэтому отдаю наружу id, чтобы обновить существующее и добавить отсутствующее

если пользователь работает с конкретным элементом и что-то в нем меняет, то может это и есть корень агрегата?

насколько я понимаю, агрегат — штука для обеспечения согласованности данных в моём случае, при добавлении листа в папку нужно проставить связи между листами. т.е. нельзя просто так взять и положить лист в папку. поэтому корень агрегата — всё-таки папка. и при этом пользователь может изменить заголовок листа… но ведь всё равно это изменение проходит через корень агрегата

насколько я понимаю, агрегат — штука для обеспечения согласованности данных в моём случае, при добавлении листа в папку нужно проставить связи между листами. т.е. нельзя просто так взять и положить лист в папку. поэтому корень агрегата — всё-таки папка. и при этом пользователь может изменить заголовок листа… но ведь всё равно это изменение проходит через корень агрегата

Может быть eventual consistency? В видео про это было вроде

насколько я понимаю, агрегат — штука для обеспечения согласованности данных в моём случае, при добавлении листа в папку нужно проставить связи между листами. т.е. нельзя просто так взять и положить лист в папку. поэтому корень агрегата — всё-таки папка. и при этом пользователь может изменить заголовок листа… но ведь всё равно это изменение проходит через корень агрегата

ммм....

папка корень агрегата но файлы не входят в этот агрегат. и списки тоже. Тебе нужна только айдишка списка

иначе с твоими тремлениями ты закончишь на том что у тебя естть один корень агрегата на вообще все операции (поскольку это единственный способ убедиться в консистентности всех связей). А это не практично

да, ФС хорошая аналогия, папка - корень агрегата и файл тоже корень агрегата, они могут быть связаны айдишками

то есть, корень агрегата - это папка, список файлов в ней - внутри агрегата но файлы - не внутри

так?

типа того, только идентификаторы

табличка

ассампшен папки - что идентификатор файла валиден

вместо списка?

список айдишек)

ну это и имел ввиду

теперь у меня вопрос - доменные ивенты

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

папка? потому, что файл - это ее часть или файл? потому, что удаляют его, и сообщает об этом он (прощается, бгг)

папка? потому, что файл - это ее часть или файл? потому, что удаляют его, и сообщает об этом он (прощается, бгг)

файловая система по определенной подписке

файловая система по определенной подписке

папка и файл - это аналогии

окей, другая аналогия - коробка и вещи в коробке коробка не владеет вещами, а просто их хранит

файловая система по определенной подписке

потому что папки тоже удалимы)

Думаю - папка. Она удаляет файл из списка и бросает ивент

давай не будем уточнять детали) вот еще подобная аналогия - телефонная книга и контакт в ней

ну собственное существование вообще не должно быть вопросом объекта

т.е. по-моему он не должен заботится о создании себя, удалении себя

да, согласен, хороший поинт

А у вещи внутри есть ссылка на "хозяина"?

Наверное зависит от контекста.

в моем кейсе есть, хоть я до сих пор не уверен в том, что это реальная бизнес-необходимость, а не сделано на поводу у UI

в моем кейсе есть, хоть я до сих пор не уверен в том, что это реальная бизнес-необходимость, а не сделано на поводу у UI

Для чего?

Какой запрос с UI, где требуется эта ссылка?

Для чего?

ну типа для того, чтобы вещь знала, где она лежит но это, в принципе, уже другая дискуссия - с ивентом я согласен

У меня вопрос. Есть у кого-нибудь примеры, связи ограниченных контекстов напрямую внутри одного инстанса? Все примеры, которые я вижу используют еще и микросервисы и обычно это http или mq связь. Я понимаю преимущества микросервиса. Просто если пока 1 сервак в проекте, не хотелось бы с точки зрения перформанса поднимать по инстансу на контекст. Хотелось бы сохранить четкие границы, чтобы потом лекго было перейти на микросервисы.

Возможно вопрос тупой, тогда поправьте плиз меня.

У меня вопрос. Есть у кого-нибудь примеры, связи ограниченных контекстов напрямую внутри одного инстанса? Все примеры, которые я вижу используют еще и микросервисы и обычно это http или mq связь. Я понимаю преимущества микросервиса. Просто если пока 1 сервак в проекте, не хотелось бы с точки зрения перформанса поднимать по инстансу на контекст. Хотелось бы сохранить четкие границы, чтобы потом лекго было перейти на микросервисы.

какая связь между микросервисами и серваками?

докеры, процессы отдельные... все спокойно может лежать на каком-нгибудь ts.micro

какая связь между микросервисами и серваками?

Просто это экономия. Прослойка http. Сериализация десериализация объектов. Больше одного инстанса джавы, внутри каждой веб сервер.

В принципе сейчас все работает на одном инстансе приложения. И огр. контексты разбиты по модулям. Работают через более менее понятные интерфейсе. Мне стало интересно как описать эту границу более четко, чтобы в коде было конкретно видно где она. Именно на практике.

Просто это экономия. Прослойка http. Сериализация десериализация объектов. Больше одного инстанса джавы, внутри каждой веб сервер.

просто суть в том что нет никакой разницы микросервисы или не микросервисы. Микросервисы не обязывают тебя делать взаимодействие по http - с точки зрения клиентского кода это будут либо ивенты либо вызовы методов. Так же как если бы все крутилось в одном и том же процессе. Просто появляются нюансы работы с распределенным приложениием. С точки зрения декомпозиции никакой разницы.

профит микросервисов не в декомпозиции а в независимом деплое (что бы делать независимое рассписание деливери разных команд). Это больше про управление и скейлинг людей. И да, этот подход пиздец чувствителен к кривой декомпозиции

просто в монолитах можно делать все то же самое но проще. И пока у тебя нет необходимости делать абсолютно независимую деливери продукта по разным людям - нет нужны в микросервисах.

а если у тебя с декомпозицией все хорошо - переход на микросервисы дело не хитрое

Задача: отсортируйте список чисел. Американский программист: q []=[]; q (x:xs) = q [y | y <- xs, y < x] ++ [x] ++ q [y | y <- xs, y >= x] Русский программист: #включить <conio.h> общедоступная функция Главная(пусто): пусто; переменная результат: список[0..9000] типа число; начало ...

а что, если я скажу тебе, что здесь не только "русские" сидят?

Задача: отсортируйте список чисел. Американский программист: q []=[]; q (x:xs) = q [y | y <- xs, y < x] ++ [x] ++ q [y | y <- xs, y >= x] Русский программист: #включить <conio.h> общедоступная функция Главная(пусто): пусто; переменная результат: список[0..9000] типа число; начало ...

ватный юморок, давай исче

чет прям второй заход пошел

аж хочу посмотреть, что еще выдаст

еще невалидного хаскеля в тред

я вон мало в своей жизни невалидного хаскеля видел

Задача: отсортируйте список чисел. Американский программист: q []=[]; q (x:xs) = q [y | y <- xs, y < x] ++ [x] ++ q [y | y <- xs, y >= x] Русский программист: #включить <conio.h> общедоступная функция Главная(пусто): пусто; переменная результат: список[0..9000] типа число; начало ...

даже приняв все стереотипы как существующие в этом нету смысла

нелегкие - дарт?

не, я с ангуляром уже года полтора не работал. сча реакты