Не микрсоервисы. Если на слабосвязанные бандлы например делить, которые в рамках одного приложения, я думаю тоже это можно назвать сервис ориентирвоанной архитектурой. Ну и сервисы м воспринимаем как "что то делающий деятель", то есть в процессе размышления ставим действия а не данные. Ну и пришел я к SOA vs ES потмоу что ты сказал что без событий не получается грамотный whole object. То есть еще раз, вопросполучается как с whole object создать бизнес транзакцию без событий. Т.е. например получаем фотку от юзера и если там порнуха, то отклоняем ее, заносим полььзователя в бан на месяц, и отсылаем емэй в ментовку например) 1.Анемичная модель: Сервис фотоприемщик, в которые инджектится фотоМодератор, в который инджектятся сервисФотореагировщик, и уже реализация этого реагирвоика содержит вызов сервисов отправки емайла, бана и т.д. Заметим, если всё делать через DI это будет ее все очень расширемо и легко кастомизируемо за счет полиморфизма в релализации интерфейса разными классами под каждую ситуацию(порно фотка, недостаточный размер фотки, мат на фотке и т.д) Все понятно, хорошо читается и расширяется. Если есть к вашей ide плагин для нормлаьной работы с di. 2. сОбытийна модель. ну вот произошло событие загрузки фотки(кстати кто его должен выбросить, фотка сама? или у нас какой то есть сущность для этого другая)? И далььше она обрабатывается всеми штуками. Тут у мнея опыта немного, так тчо не смогу подробно расписать, но идея мне понятна. 3. whole object без событий или то что я называл богатой доменной моделью. Вообще хз что куда пихать? вот дернули метод контроллера загрузить фотку, и дальше что опять нам нужен какой то фотоприемщик, но это насколько я понимаю плохое назваание для сущности(так как отглагольное, и по сути тот же сервис из пункта 1). Но вот допустим приняли мы фотку, и дальше какое ее взаимодествие и с кем? Я не могу понять как бить ответственности между сущностями предметной области, их вообще выделять? Если в анемичной или событийной модели я просто рассматирваю данные(объект фотки) котоырй проходит через разные фильтры/преобразоователи и с которым в итоге что то происходит - могу это ясно изобразить и в коде и на бумаге. Тот тут у меня ступор

доменный ивент - это факт. Разве у тебя SaveChanges не является коммитом и точкой завершения бизнес транзакции? и разве не только тогда ивенты превращаются в факты?

Нет. SaveChanges может быть несоклько. Фактом явзяется успешное сохранение данных и последующий успешный коммит транзакции после этого.

есть разница между транзакцией в базе и логической транзакцией. ТАм картинка есть с двумя агрегатами разными

Вот фишка в том, что когда CQRS - то ты в один момент времени с одним агрегатом работаешь.

это не CQRS фишка, это в целом суть агрегата.

Ну если положить его на CQRS, То ровно это и получится)

Не микрсоервисы. Если на слабосвязанные бандлы например делить, которые в рамках одного приложения, я думаю тоже это можно назвать сервис ориентирвоанной архитектурой. Ну и сервисы м воспринимаем как "что то делающий деятель", то есть в процессе размышления ставим действия а не данные. Ну и пришел я к SOA vs ES потмоу что ты сказал что без событий не получается грамотный whole object. То есть еще раз, вопросполучается как с whole object создать бизнес транзакцию без событий. Т.е. например получаем фотку от юзера и если там порнуха, то отклоняем ее, заносим полььзователя в бан на месяц, и отсылаем емэй в ментовку например) 1.Анемичная модель: Сервис фотоприемщик, в которые инджектится фотоМодератор, в который инджектятся сервисФотореагировщик, и уже реализация этого реагирвоика содержит вызов сервисов отправки емайла, бана и т.д. Заметим, если всё делать через DI это будет ее все очень расширемо и легко кастомизируемо за счет полиморфизма в релализации интерфейса разными классами под каждую ситуацию(порно фотка, недостаточный размер фотки, мат на фотке и т.д) Все понятно, хорошо читается и расширяется. Если есть к вашей ide плагин для нормлаьной работы с di. 2. сОбытийна модель. ну вот произошло событие загрузки фотки(кстати кто его должен выбросить, фотка сама? или у нас какой то есть сущность для этого другая)? И далььше она обрабатывается всеми штуками. Тут у мнея опыта немного, так тчо не смогу подробно расписать, но идея мне понятна. 3. whole object без событий или то что я называл богатой доменной моделью. Вообще хз что куда пихать? вот дернули метод контроллера загрузить фотку, и дальше что опять нам нужен какой то фотоприемщик, но это насколько я понимаю плохое назваание для сущности(так как отглагольное, и по сути тот же сервис из пункта 1). Но вот допустим приняли мы фотку, и дальше какое ее взаимодествие и с кем? Я не могу понять как бить ответственности между сущностями предметной области, их вообще выделять? Если в анемичной или событийной модели я просто рассматирваю данные(объект фотки) котоырй проходит через разные фильтры/преобразоователи и с которым в итоге что то происходит - могу это ясно изобразить и в коде и на бумаге. Тот тут у меня ступор

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

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

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

Что значит сущность юзераа? Он же не сам себе ммодерирует, он пытается заагрузить плохую фотку, а кто то другой должен ему помешать. Ну или допустимм сделаю я метод uploadPhoto...и что мне в сущность инджектить разные валидаторы? и объекты реаагирующие на на разные итоги ваалидации?

Что значит сущность юзераа? Он же не сам себе ммодерирует, он пытается заагрузить плохую фотку, а кто то другой должен ему помешать. Ну или допустимм сделаю я метод uploadPhoto...и что мне в сущность инджектить разные валидаторы? и объекты реаагирующие на на разные итоги ваалидации?

Я думал как сделать - есть команды/запросы и их обработчики (CQRS, не без ES). Прилетает мне команда - я резолвлю обработчик, вызываю его, передавая в него команду. Далее, в ней самой я вызываю доменные сервисы, которые в результате своих действий возвращают эвенты, которые я просто складываю в список. Далее, после успешного коммита транзакции - я пуляю список эвентов в медиатор, который уже будет уведомлять тех, кто эти эвенты ожидает получить. Что скажешь?

Я думал как сделать - есть команды/запросы и их обработчики (CQRS, не без ES). Прилетает мне команда - я резолвлю обработчик, вызываю его, передавая в него команду. Далее, в ней самой я вызываю доменные сервисы, которые в результате своих действий возвращают эвенты, которые я просто складываю в список. Далее, после успешного коммита транзакции - я пуляю список эвентов в медиатор, который уже будет уведомлять тех, кто эти эвенты ожидает получить. Что скажешь?

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

да, передай их просто аргументами в метод

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

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

а кто должен это делать?

что то мои слова напоминают мне то что я слышал о функциональшине - типо есть данные и хуяришь их по цеопчке йункция

не, твои идеи это банальные процедуры, до фп далековато

И связанность сильная получается

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

почему пользователь не должен заниматься проверкой собственных инвариантов?

я бы не отказался от объекта, который вместо меня может код писать :3

почему пользователь не должен заниматься проверкой собственных инвариантов?

Не собственных!! Кейс с фоткой, с точки зреня пользооваателя всё ок, он увидел возможность загрузить картинку он берет картинку и грузит. Если он будет проверять по каким то бизнесс правилам(порно не порно/ экстремизм не экстремизм) или инфраструтурным(формат jpeg/gif, минимлаьный размер) то получается чо он лезет кудаа не должен - в првила нашего приложения. И какого хрена он сам себя валидирует, где гранатия что валидция пройдет как надо. Давайте представим что вот пользователь просто грузит фотки, у него оодна обдяанность попытатьс язагрузить фотку - он не мент, не почтальон, не контроллер, он просто нажимает на субмит/кидает фотку в почтовый ящик и т.д. А ты предлагаешь его каким то год обджектом сделать который будет абсоютносамодостаточен и будет иметь доступ к львиной доил бизнесс логики

Не собственных!! Кейс с фоткой, с точки зреня пользооваателя всё ок, он увидел возможность загрузить картинку он берет картинку и грузит. Если он будет проверять по каким то бизнесс правилам(порно не порно/ экстремизм не экстремизм) или инфраструтурным(формат jpeg/gif, минимлаьный размер) то получается чо он лезет кудаа не должен - в првила нашего приложения. И какого хрена он сам себя валидирует, где гранатия что валидция пройдет как надо. Давайте представим что вот пользователь просто грузит фотки, у него оодна обдяанность попытатьс язагрузить фотку - он не мент, не почтальон, не контроллер, он просто нажимает на субмит/кидает фотку в почтовый ящик и т.д. А ты предлагаешь его каким то год обджектом сделать который будет абсоютносамодостаточен и будет иметь доступ к львиной доил бизнесс логики

ну не нравится тебе метод в юзере, сделай объект Photo и занеси это все туда

Наверно мне не нравится идея саамовалидации как я понял

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

Бугаенко вроде как высказывается против DDD, но при этом в том докладе, что скидывали вчера, все тезисы соотстветсвуют DDD (типа не выносить логику объекта из объекта)

Ну хз а допустим юзер грузит фотку а у меня может быть разные варианты с ней - определить в соответствующую категорию в зависимости от того что на ней, может отклонить и добавить юзера, а может вообще описать текстом ее содержимое. + для разных разделов сайта разныеправила модерации. Это что мне сколко классов фотко создавать? Или это все в одном классе, где фотка сама себя анализирует идентефицирует, валидирует и модерирует. Какая то слишком уж самостоятельная сущность и многогранная

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

Я думал как сделать - есть команды/запросы и их обработчики (CQRS, не без ES). Прилетает мне команда - я резолвлю обработчик, вызываю его, передавая в него команду. Далее, в ней самой я вызываю доменные сервисы, которые в результате своих действий возвращают эвенты, которые я просто складываю в список. Далее, после успешного коммита транзакции - я пуляю список эвентов в медиатор, который уже будет уведомлять тех, кто эти эвенты ожидает получить. Что скажешь?

Ну хз а допустим юзер грузит фотку а у меня может быть разные варианты с ней - определить в соответствующую категорию в зависимости от того что на ней, может отклонить и добавить юзера, а может вообще описать текстом ее содержимое. + для разных разделов сайта разныеправила модерации. Это что мне сколко классов фотко создавать? Или это все в одном классе, где фотка сама себя анализирует идентефицирует, валидирует и модерирует. Какая то слишком уж самостоятельная сущность и многогранная

просто предстявляешь, что вместо ивента ты процедурку вызваешь

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

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