Без чейндж трекинга, конечно, можно сохранять, но все-таки у нас ddd и исключать такую фичу - не стоит. Поэтому репозитарий слой обычно про чейндж трекер ничего не знает, он работает с бд и ограничено с агрегатами (см. п.2) - перегружать логикой не стоит.
Каждый агрегат унаследован от RootAggregate в котором есть: IReadOnlyCollection<IDomainEvent> Events { get; } void ClearDomainEvents(); void AddDomainEvent(IEvent @event); - это в доменном слое. А дальше уже Application слой. Подписка идет через специальные EventHandler (дженерик обычно, где типы TAggregate и TDomainEvent). Обрабтываются события в апликейшн на уровне UnitOfWork в конкретном хендлере.
2)
>>> Нужно будет защититься
Однозначно - да. У нас же не го - мы себе можем позволить базовый комфорт. Пример: связка internal + дружественные сборки - помогут предовратить неправильную эксплуатацию аггрегата.
Ну, если подразумевать агрегат по Эвансу, то рецепт его сборки из бд следующий: оптимизированная CTE, желательно Dapper (удобен он, не отнять), и дальше в репозитрии сборка агргегата через CollectionsMarshal и спанов с использование конструкторов или стат методов агрегата. Производительность по сравнению с ef core ощутимая. При реализациии сразу видишь и бд (запрос) и агрегат - уже понимаешь варианты оптимизаци.
А при создании агрегата без сохранения (формат ин мемори) или перед сохранением, тут чаще всего вообще не нужен персистенс слой (читать бд и конкретные поля таблиц) - все в аппликейшн через те же, а может и другие более подходящие, чем используемые в репозитариях, конструкторы или стат методы агрегата.
В обоих случаях мы получаем валидный агргегат соответствующий всем учтенным в нем бизнес правилам.
Лучше не тащить orm, особенно в ddd. Да, ef core крут и даст фору многим, но все-таки каждый инструмент под свою задачу. Решился на ddd, тогда не надо экономить на sql.
Попробовать перестать крутиться вокруг агрегатов, как самых что ни на есть самых самостоятельных участников системы и дать шанс сущностям (вот этим несамостоятельным) - размыть границы. Это даст гибкости.
Забыть про dto. 1001-е лихо сформированное дтошка добьет проект и ddd тут не спасет. Dto в больших проектах нет. Есть request, response. И тут появляются хэндлеры - да, но не mediatr.
Пересмотреть репозитарии и их имплементацию, отстуствие orm дает крутые бонусы и отличную управляемость с производительностью, если опять же слепо не следовать канонам и не тащить агрегаты на каждый запрос. Как следствие появляется некоторый промежуточный инструмент компромисса: response. Но с ним надо быть осторожно. Здесь больше про оптимизацию.
Не забывать про ValueObjects. Бизнес скажет спасибо.
веб копал в авалонии полгода назад, - это еще не прод. те же самые js интеропы работают непредсказуемо, может что-то уже и пофиксилось. Мобильные платформы в авалонии скорее всего - да, чуть поживее, чем веб, но тоже есть нюансы. Андроид не копал, а вот ios - мало компонентов, много нужно писать нативки, ну и прохождение модерации в эпп стор - надо постараться.
Ради справедливости надо отметить, хочешь хороший desktop на маке или бодрое ios приложение: вооружаешься 6ым swift, concurrency, комбайном с их mvvm, докой эппла по ui - и получится. Остальное, имею ввиду другие кроссплатформенные решения (не только авалония), в большинстве коммерческих случаев, - полумеры.
Можно и ddd на го с монолитами - отчего ж нет. Были бы бюджеты, чтобы это все поддерживать. На мой взгляд это не тот инструмент, чтобы можно было как джавах или шарпах ооп подход реализовывать - обычно костыль на костыле выходит. По моему опыту и поддержка потом болезненная или дорогая выходит.
С дженериками в го, кстати, не так все богато как в шарпах, но зато в go кодогенерация удобнее, на мой взгляд. Остальное вкусовщина и дело привычки. Для компактных быстрых микросервисов - гошка может приятно удивить. Памяти он есть действительно меньше и этого не отнять (ну если не АОТ сравниваем).
Для меня проблема с го следующая: его идеомы, когда пишешь на нем часто - привыкаешь, понимаешь где случайно не скопировать весь массив, где лишний раз не захватить переменную, и уже появляется чутье, как избежать рейс кондишенев. Но как только попадаешь в родные шарпы и там проводишь месяц другой в зоне комфорта (тот же ddd без костылей, прогнозируемые в поддержке монолиты) - переключаться на го сложно - опять надо привыкать. Кстати с шарпов на джаву и с джавы на шарпы такого эффекта не ловил, хотя давно на джаве уже не писал.
Может и без, но ms влияет достаточно сильно. Бэк на .net - это уже сформированный зрелый кейс, который вобрал вообще в себя лучшие практики и скорость реализации проекта заметно возрасла (и дело не в ef core) - альтернатив с таким сочетанием: производительность, богатый набор фич, которые реально помогают писать быстро и безопасно, - на рынке практически нет.
А вот мобильная и десктоп кросплатформа с maui пошла куда-то не туда. Хочется на все это махнуть и либо авалонию (если десктоп) брать, либо нативку на свифте, если ios - ну не тянут, столько лет, а все на одном месте топчутся.
Да, как слезть с шарпов-то? Особенно после 8/9/10 .net.
Go - такая себе альтернатива. Особенно после стабильного хоть и с ограничениями aot потребность в go вообще под вопросом, хотя раньше прям выручал, если надо было оч мало памяти потреблять и без джита.
Java? Мистер монстр Spring? Или все же kotlin - а если он, то опять спринг или все же модный в узких кругах ктор?
Питон с фастапи - уже из другой весовой категории.
Что будет мило шарписту так же, как родные дотнеты?
1) у вас портрет потребителя ваших курсов достаточно широкий. а что на счет детей? планируете ли под них делать специализированные курсы, ведь формат "для всех" и для детского восприятия - они разные?
2) что насчет unity? планируете ли курсы по нему? ведь спрос достаточно большой на него.
Сам время от времени пишу на go и язык нравиться, но он "нелегкий" (тонкостей неочевидных очень много), как думают многие, и монолит на нем написать приближенный к ddd - это...., но это не для этого - а именно монолит (хотя бы модульный) в противовес пачке микросервисов (кто ж эту пачку будет сопровождать, если не большая команда разработчиков) может способствовать к экономии бюджета.
По моему опыту перфоманс же по памяти у go более чем в 8 раз выше по сравнению с jit компиляцией .net (если не намудрить с копированием слайсов и работой с мапами). Если же мы включаем .net AOT, то порой go на 20-30% проигрывает .net-у, а порой одинаково. Глубоко в сравнение давно уже не копал.
По поводу java - я так понимаю собираетесь делать по ней курс. А почему java, а не kotlin ?
А на чем писать, если не на .net?))) одна из немногих экономически оправданных платформ, на которой еще можно реализовать рабочий бизнес продукт с хорошей производительностью, не раздувая штат разработчиков.
@Fearning Ну обычно сервера на коллокейшн хостингах берут в стоечном корпусе, чтобы потом можно было эргономично в стойках размещать, но и стоят они соответствующе, а тут дешево и сердито, да еще и распределенно. Вот только вопрос, где вот такие мини дадут разместить, если потянет в прод?
1)
>>> а как сохранять без ченж трекинга?
Без чейндж трекинга, конечно, можно сохранять, но все-таки у нас ddd и исключать такую фичу - не стоит. Поэтому репозитарий слой обычно про чейндж трекер ничего не знает, он работает с бд и ограничено с агрегатами (см. п.2) - перегружать логикой не стоит.
Каждый агрегат унаследован от RootAggregate в котором есть: IReadOnlyCollection<IDomainEvent> Events { get; } void ClearDomainEvents(); void AddDomainEvent(IEvent @event); - это в доменном слое. А дальше уже Application слой. Подписка идет через специальные EventHandler (дженерик обычно, где типы TAggregate и TDomainEvent). Обрабтываются события в апликейшн на уровне UnitOfWork в конкретном хендлере.
2)
>>> Нужно будет защититься
Однозначно - да. У нас же не го - мы себе можем позволить базовый комфорт. Пример: связка internal + дружественные сборки - помогут предовратить неправильную эксплуатацию аггрегата.
Ну, если подразумевать агрегат по Эвансу, то рецепт его сборки из бд следующий: оптимизированная CTE, желательно Dapper (удобен он, не отнять), и дальше в репозитрии сборка агргегата через CollectionsMarshal и спанов с использование конструкторов или стат методов агрегата. Производительность по сравнению с ef core ощутимая. При реализациии сразу видишь и бд (запрос) и агрегат - уже понимаешь варианты оптимизаци.
А при создании агрегата без сохранения (формат ин мемори) или перед сохранением, тут чаще всего вообще не нужен персистенс слой (читать бд и конкретные поля таблиц) - все в аппликейшн через те же, а может и другие более подходящие, чем используемые в репозитариях, конструкторы или стат методы агрегата.
В обоих случаях мы получаем валидный агргегат соответствующий всем учтенным в нем бизнес правилам.
Несколько соображений.
Лучше не тащить orm, особенно в ddd. Да, ef core крут и даст фору многим, но все-таки каждый инструмент под свою задачу. Решился на ddd, тогда не надо экономить на sql.
Попробовать перестать крутиться вокруг агрегатов, как самых что ни на есть самых самостоятельных участников системы и дать шанс сущностям (вот этим несамостоятельным) - размыть границы. Это даст гибкости.
Забыть про dto. 1001-е лихо сформированное дтошка добьет проект и ddd тут не спасет. Dto в больших проектах нет. Есть request, response. И тут появляются хэндлеры - да, но не mediatr.
Пересмотреть репозитарии и их имплементацию, отстуствие orm дает крутые бонусы и отличную управляемость с производительностью, если опять же слепо не следовать канонам и не тащить агрегаты на каждый запрос. Как следствие появляется некоторый промежуточный инструмент компромисса: response. Но с ним надо быть осторожно. Здесь больше про оптимизацию.
Не забывать про ValueObjects. Бизнес скажет спасибо.
Профит.
веб копал в авалонии полгода назад, - это еще не прод. те же самые js интеропы работают непредсказуемо, может что-то уже и пофиксилось. Мобильные платформы в авалонии скорее всего - да, чуть поживее, чем веб, но тоже есть нюансы. Андроид не копал, а вот ios - мало компонентов, много нужно писать нативки, ну и прохождение модерации в эпп стор - надо постараться.
Ради справедливости надо отметить, хочешь хороший desktop на маке или бодрое ios приложение: вооружаешься 6ым swift, concurrency, комбайном с их mvvm, докой эппла по ui - и получится. Остальное, имею ввиду другие кроссплатформенные решения (не только авалония), в большинстве коммерческих случаев, - полумеры.
Можно и ddd на го с монолитами - отчего ж нет. Были бы бюджеты, чтобы это все поддерживать. На мой взгляд это не тот инструмент, чтобы можно было как джавах или шарпах ооп подход реализовывать - обычно костыль на костыле выходит. По моему опыту и поддержка потом болезненная или дорогая выходит.
С дженериками в го, кстати, не так все богато как в шарпах, но зато в go кодогенерация удобнее, на мой взгляд. Остальное вкусовщина и дело привычки. Для компактных быстрых микросервисов - гошка может приятно удивить. Памяти он есть действительно меньше и этого не отнять (ну если не АОТ сравниваем).
Для меня проблема с го следующая: его идеомы, когда пишешь на нем часто - привыкаешь, понимаешь где случайно не скопировать весь массив, где лишний раз не захватить переменную, и уже появляется чутье, как избежать рейс кондишенев. Но как только попадаешь в родные шарпы и там проводишь месяц другой в зоне комфорта (тот же ddd без костылей, прогнозируемые в поддержке монолиты) - переключаться на го сложно - опять надо привыкать. Кстати с шарпов на джаву и с джавы на шарпы такого эффекта не ловил, хотя давно на джаве уже не писал.
Может и без, но ms влияет достаточно сильно. Бэк на .net - это уже сформированный зрелый кейс, который вобрал вообще в себя лучшие практики и скорость реализации проекта заметно возрасла (и дело не в ef core) - альтернатив с таким сочетанием: производительность, богатый набор фич, которые реально помогают писать быстро и безопасно, - на рынке практически нет.
А вот мобильная и десктоп кросплатформа с maui пошла куда-то не туда. Хочется на все это махнуть и либо авалонию (если десктоп) брать, либо нативку на свифте, если ios - ну не тянут, столько лет, а все на одном месте топчутся.
Так, подождите, ну а как же, что в России шарпы неактуальны и никакой новый проект не пишется на шарпах: только на го, питонах и джаве 11 ?
У меня друзья получали сеньерские офферы и от вб (го) и озон (шарпы) - там все было около 350 плюс премия. Откуда зп в 500к+ ?
Нет, сам специализируюсь на бекенд разработке, но это не мешает иногда посматривать и в мобильный натив и в unity)
Спасибо за статью!
В основном разработку под vr делаете на pc?
Какую vr-гарнитуру под мак посоветуете для пробы пера в vr-unity?
>>> Не зацикливайтесь на одном языке
Да, как слезть с шарпов-то? Особенно после 8/9/10 .net.
Go - такая себе альтернатива. Особенно после стабильного хоть и с ограничениями aot потребность в go вообще под вопросом, хотя раньше прям выручал, если надо было оч мало памяти потреблять и без джита.
Java? Мистер монстр Spring? Или все же kotlin - а если он, то опять спринг или все же модный в узких кругах ктор?
Питон с фастапи - уже из другой весовой категории.
Что будет мило шарписту так же, как родные дотнеты?
Сергей, вопросы:
1) у вас портрет потребителя ваших курсов достаточно широкий. а что на счет детей? планируете ли под них делать специализированные курсы, ведь формат "для всех" и для детского восприятия - они разные?
2) что насчет unity? планируете ли курсы по нему? ведь спрос достаточно большой на него.
Каждый инструмент хороший для своих задач.
Сам время от времени пишу на go и язык нравиться, но он "нелегкий" (тонкостей неочевидных очень много), как думают многие, и монолит на нем написать приближенный к ddd - это...., но это не для этого - а именно монолит (хотя бы модульный) в противовес пачке микросервисов (кто ж эту пачку будет сопровождать, если не большая команда разработчиков) может способствовать к экономии бюджета.
По моему опыту перфоманс же по памяти у go более чем в 8 раз выше по сравнению с jit компиляцией .net (если не намудрить с копированием слайсов и работой с мапами). Если же мы включаем .net AOT, то порой go на 20-30% проигрывает .net-у, а порой одинаково. Глубоко в сравнение давно уже не копал.
По поводу java - я так понимаю собираетесь делать по ней курс. А почему java, а не kotlin ?
А на чем писать, если не на .net?))) одна из немногих экономически оправданных платформ, на которой еще можно реализовать рабочий бизнес продукт с хорошей производительностью, не раздувая штат разработчиков.
@Fearning Ну обычно сервера на коллокейшн хостингах берут в стоечном корпусе, чтобы потом можно было эргономично в стойках размещать, но и стоят они соответствующе, а тут дешево и сердито, да еще и распределенно. Вот только вопрос, где вот такие мини дадут разместить, если потянет в прод?
Реализация супер!
А если захочется где-нибудь этот кластер захостить, какие варианты размещения есть? В обычную стойку в коллокейшене это не запихнешь.