Спасибо за рассказ об особенностях, полезно! И классно ответили на кучу вопросов, которые возникают при проектировании. Спасибо за примеры! Супер доклад - рассмотрено столько инструментов за такое короткое время!
Докладчик интересно рассказывает. Спасибо. Но имхо идея с разбиением на много сервисов не то что одного ограниченного контекста, а даже одного агрегата и потом работа со всем этим великолепием по сети через синхронный API звучит как дикая дичь. И это при том, что все они шарят одну и ту же БД.
Спасибо за доклад. Эх, жаль нет примера шаблона проекта для изучения... Основные идеи в теории понятны но этого недостаточно для объективной оценки качества и удобства поддержки получаемого кода.
"мы разбили агрегат, в сервисе А у нас кусочек этого агрегата, а в сервисе Б другой кусочек этого агрегата" - а может называть это агрегатами, а не кусочками агрегата? большие агрегаты - могут быть симптомом того, что моделируется не поведение, а данные я вот агрегат рассматриваю как процесс, в процессе как правило можно выделить более мелкие составляющие, это тоже процессы все наше приложение по сути набор процессов, объединяющиеся в цепочки.. и каждый узел цепочки - и есть агрегат, представляющий в первую очередь поведение + кусочек стейта и стейт на самом деле не так важен, скорее, стейт необходим агрегату чтобы тот мог делать свои дела ну еще транзакционная согласованность (ничоси какие слова знаю) а еще интересное и увлекательное занятие это рисовать схемки и пытаться разбить что-то на агрегаты так, чтобы как можно меньше зависимостей было, возможных несогласованностей, чтобы ссылки были на неизменяемые вещи и все такое, модели должны быть в первую очередь полезными (правильных моделей не существует) нормальный размер агрегата - немножко полей + пара-тройка методов, если полей 20 и методов штук 10 - это жирный агрегат, все херня Саня, переделывай а еще непонятно зачем сильно дробить на сервисы... только потому что в слове "микросервисы" затесалось "микро"? неужели у вас 100500 команд? еще момент про внешние сервисы - почти всегда плохая идея заводить у себя какую-то сущность которая отражает сущность из внешнего сервиса (или делать у себя точно такие же статусы, как во внешнем сервисе.. ох уж эти статусы), внешний сервис - не наш домен, не надо его тянуть себе, домен - наше все, внешние сервисы, всякие фронтенды и привычки не должны диктовать нам как моделировать ну и банально лишняя синхронизация + как правило от внешнего сервиса нужно что-то конкретное - например, номер какой-то забрать, а не десяток полей и забрать это что-то обычно нужно в какой-то конкретный момент чьего-то жизненного цикла.. про слои... тут уж кому как нравится, я например делаю так - в домене только агрегаты и доменные сервисы, в аппликейшене - юзкейсы, интерфейсы реп, гейтвеев и интерфейсы объектов, которые служат аргументами юзкейсов аппликейшн сервисы - вообще не понимаю что за зверь такой.. а еще у меня почти нет никаких фабрик, возможно потому что агрегаты простые и фабрики не нужны почему интерфейсы реп/гейтвеев в аппликейшене - потому что они юзаются в первую очередь там, в домене они незачем, только лишний соблазн наговнякать что-нибудь сомнительное (вы ведь не прокидываете гейтвеи внутрь агрегатов?) а логику делить на аппликейшн логику и доменную.. было дело, но дело неблагодарное, кмк например, порядок вызовов агрегатов - вполне себе важная логика, просто чуть менее важная чем та что в домене оно вообще все выглядит так, что глобально-то у нас 2 слоя - домен и не домен (инфраструктура), это не значит что у меня две папки Domain и Infrastructure, это не так - это из серии что мне лично так проще мыслить, чем делить логику на множество сортов и много сомневаться про валидацию и правила - это такая вещь, которая может неплохо так способствовать вытеканию логики из домена p.s. не воспринимайте как критику, тут я скорее описал свой опыт и мысли)
@@LotmineRu я даже вашего вопроса не понял. Анемичные модели это не ддд агрегаты как процессы это не ддд, возможно это просто "сервисное программирование" по сути таже самая процедурщина
Тебе не кажется) я бы сказал, микросервис на базе одного агрегата - это прям минимальная единица разбиения и это может быть нормально (в каких случаях - хз, каждый случай надо оценивать индивидуально), но кто дробит прям всё по умолчанию по 1 агрегату или пытается раздробить еще мельче - наркоманы то что автор говорил что они агрегат дробят на кусочки - хз как это, но скорее всего это должно быть дробление агрегата на более мелкие агрегаты кмк оптимальный вариант это 1 ограниченный контекст - 1 микросервис.. главное, эти ограниченные контексты правильно найти, хехе а вообще можно не спешить делить на микросервисы... даже просто заниматься моделированием и при этом держать в голове "представим, что наши модули - микросервисы" - очень полезно
Спасибо за рассказ об особенностях, полезно! И классно ответили на кучу вопросов, которые возникают при проектировании. Спасибо за примеры! Супер доклад - рассмотрено столько инструментов за такое короткое время!
Докладчик интересно рассказывает. Спасибо. Но имхо идея с разбиением на много сервисов не то что одного ограниченного контекста, а даже одного агрегата и потом работа со всем этим великолепием по сети через синхронный API звучит как дикая дичь. И это при том, что все они шарят одну и ту же БД.
Спасибо, интересный доклад.
Спасибо за доклад. Эх, жаль нет примера шаблона проекта для изучения... Основные идеи в теории понятны но этого недостаточно для объективной оценки качества и удобства поддержки получаемого кода.
34:33 извините, не понял почему вы утверждаете, что конструкция a() && b() хуже чем a() || b() 😀
"мы разбили агрегат, в сервисе А у нас кусочек этого агрегата, а в сервисе Б другой кусочек этого агрегата" - а может называть это агрегатами, а не кусочками агрегата?
большие агрегаты - могут быть симптомом того, что моделируется не поведение, а данные
я вот агрегат рассматриваю как процесс, в процессе как правило можно выделить более мелкие составляющие, это тоже процессы
все наше приложение по сути набор процессов, объединяющиеся в цепочки.. и каждый узел цепочки - и есть агрегат, представляющий в первую очередь поведение + кусочек стейта и стейт на самом деле не так важен, скорее, стейт необходим агрегату чтобы тот мог делать свои дела
ну еще транзакционная согласованность (ничоси какие слова знаю)
а еще интересное и увлекательное занятие это рисовать схемки и пытаться разбить что-то на агрегаты так, чтобы как можно меньше зависимостей было, возможных несогласованностей, чтобы ссылки были на неизменяемые вещи и все такое, модели должны быть в первую очередь полезными (правильных моделей не существует)
нормальный размер агрегата - немножко полей + пара-тройка методов, если полей 20 и методов штук 10 - это жирный агрегат, все херня Саня, переделывай
а еще непонятно зачем сильно дробить на сервисы... только потому что в слове "микросервисы" затесалось "микро"? неужели у вас 100500 команд?
еще момент про внешние сервисы - почти всегда плохая идея заводить у себя какую-то сущность которая отражает сущность из внешнего сервиса (или делать у себя точно такие же статусы, как во внешнем сервисе.. ох уж эти статусы), внешний сервис - не наш домен, не надо его тянуть себе, домен - наше все, внешние сервисы, всякие фронтенды и привычки не должны диктовать нам как моделировать
ну и банально лишняя синхронизация + как правило от внешнего сервиса нужно что-то конкретное - например, номер какой-то забрать, а не десяток полей
и забрать это что-то обычно нужно в какой-то конкретный момент чьего-то жизненного цикла..
про слои... тут уж кому как нравится, я например делаю так - в домене только агрегаты и доменные сервисы, в аппликейшене - юзкейсы, интерфейсы реп, гейтвеев и интерфейсы объектов, которые служат аргументами юзкейсов
аппликейшн сервисы - вообще не понимаю что за зверь такой.. а еще у меня почти нет никаких фабрик, возможно потому что агрегаты простые и фабрики не нужны
почему интерфейсы реп/гейтвеев в аппликейшене - потому что они юзаются в первую очередь там, в домене они незачем, только лишний соблазн наговнякать что-нибудь сомнительное (вы ведь не прокидываете гейтвеи внутрь агрегатов?)
а логику делить на аппликейшн логику и доменную.. было дело, но дело неблагодарное, кмк
например, порядок вызовов агрегатов - вполне себе важная логика, просто чуть менее важная чем та что в домене
оно вообще все выглядит так, что глобально-то у нас 2 слоя - домен и не домен (инфраструктура), это не значит что у меня две папки Domain и Infrastructure, это не так - это из серии что мне лично так проще мыслить, чем делить логику на множество сортов и много сомневаться
про валидацию и правила - это такая вещь, которая может неплохо так способствовать вытеканию логики из домена
p.s. не воспринимайте как критику, тут я скорее описал свой опыт и мысли)
"я вот агрегат рассматриваю как процесс" - и вот с этого момента мы уже говорим не о ДДД)))
а о обычных сервисах и анемичных моделях.
@@delifeful как связаны анемик модели с рассматриванием агрегатов как процессов? думаю, что никак
@@LotmineRu я даже вашего вопроса не понял. Анемичные модели это не ддд агрегаты как процессы это не ддд, возможно это просто "сервисное программирование" по сути таже самая процедурщина
От чего-то кажется, что все эти микросервисы на базе одного агрегата полная ерунда учитывая многочисленные взаимосвязи между агрегатами
Тебе не кажется) я бы сказал, микросервис на базе одного агрегата - это прям минимальная единица разбиения и это может быть нормально (в каких случаях - хз, каждый случай надо оценивать индивидуально), но кто дробит прям всё по умолчанию по 1 агрегату или пытается раздробить еще мельче - наркоманы
то что автор говорил что они агрегат дробят на кусочки - хз как это, но скорее всего это должно быть дробление агрегата на более мелкие агрегаты
кмк оптимальный вариант это 1 ограниченный контекст - 1 микросервис.. главное, эти ограниченные контексты правильно найти, хехе
а вообще можно не спешить делить на микросервисы... даже просто заниматься моделированием и при этом держать в голове "представим, что наши модули - микросервисы" - очень полезно
Спасибо за доклад!
18:30 - Класс Entity показан с бизнес-логикой в качестве примера или это реально работающая схема?
Мы пишем именно так, вполне работоспособно
@@user-ju3tq9jg3m слабый аргумент 😀, при всем уважении.