Выделяете ли вы исключения в отдельную папку? И если не выделяете, используете ли суффикс Exception?

когда как для обоих вопросов

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

иногда еще ползуюсь Error суффиксом

Выделяете ли вы исключения в отдельную папку? И если не выделяете, используете ли суффикс Exception?

Я выделяю, удобно искать их потом, особенно если делите проект по контекстам

Выделяете ли вы исключения в отдельную папку? И если не выделяете, используете ли суффикс Exception?

Не использую суффикс в случае понятности исключения типа как UserNotFound

Я выделяю, удобно искать их потом, особенно если делите проект по контекстам

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

А вот про это вопрос кстати:

выделяю и до кучи в отдельную папку в рамках модуля) вкусовщина, как по мне. Ни за, ни против особых моментов нет) ну типа лишние 5 буковок написать не западло и всё такое)

выделяю и до кучи в отдельную папку в рамках модуля) вкусовщина, как по мне. Ни за, ни против особых моментов нет) ну типа лишние 5 буковок написать не западло и всё такое)

+++

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

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

Да, именно так. И внутри модуля кладу исключения в папку Exceptions, просто удобно для себя

Я склоняюсь к сборщику, так как это его все таки ошибка, что не указан вотчдог

а сам вотчдог не должен знать обязательный он илнет

Я склоняюсь к сборщику, так как это его все таки ошибка, что не указан вотчдог

Думаю правильно так

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

что-то типа AOP?

а сам вотчдог не должен знать обязательный он илнет

Это же не исключения самого вотчера

что-то типа AOP?

получается, что так

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

Удобно с таким работать?) Ну с вотчерами

Это же не исключения самого вотчера

поддерживаю

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

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

Интересно) ну в принципе довольно гибко получается, наверно доку на такие штуки надо иметь)

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

и смущает полотно в 300+ строк

в одном методе

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

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

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

в саге будет больше 300 строк) если уж прям размазывать от души)

ну я думаю что саги все ж тут рано))

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

но я пока могу только на простых кейсах прокручивать..

вот как у Макса)

ее опять ProcessManager ??

я же уже вроде спрашивал)

и смущает полотно в 300+ строк

а чем смущает?

ну процесс менеджер это когда у тебя процесс со стэйтом который надо держать дольше чем запрос

это как наши с тобой платежки

вот как у Макса)

ну мои саги (которые на работе пилю) ещё попробуй пойми) там довольно большая блок-схема получается)

ну процесс менеджер это когда у тебя процесс со стэйтом который надо держать дольше чем запрос

а, тогда охрана отмена)

наркоманская схема, все дела

наркоманская схема, все дела

да норм, я разобрался ж)

а чем смущает?

как показывает практика, где 300, там через месяц уже 500, плюс с десяток if - else - if

как показывает практика, где 300, там через месяц уже 500, плюс с десяток if - else - if

убирай if/else

в отдельные сервисы

в VO

куда угодно

ты разобрался в том, как они сами работают) а как в них бизнесс-логика обрабатывается - другой момент)

как показывает практика, где 300, там через месяц уже 500, плюс с десяток if - else - if

так это ж не про саги

полотнище должно оставаться линейным

если у тебя много зависимостей - убирай логику

в целом, всё говно в сервисах, а саги типа не при чём) если/то

да, саги форсят разделять лучше... но это не точно)

угу) есть у меня сага, которая по пути инициализирует ещё 3) такое себе удовольствие, если честно)

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

оно работает, но вот за прозрачность схемы не ручаюсь)

а сага - эт не транзакция?)

а сага - эт не транзакция?)

транзакция)

отчасти) но да ладно, любителей обмазаться команд басами нет, пойду дальше квартиру убирать)

а сага - эт не транзакция?)

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

ну то бишь да транзакция короч убеди...(

я поэтому выше и написал, что отчасти. Всё от использования зависит, имхо. Тебя никто не заставляет откатывать что-то. Или не бросить на пол пути

сохранив "что получилось"

в +/- большом flow по саге ещё попробуй роллбэк сообрази

в принципе довольно коварный инструмент, который оставляет большой запас для "творчества". И это иногда может стать проблемой)

А можно на пальцах про саги?

Ну и если не затруднит - где подробнее прочитать можно? Что это такое и с чем их готовить?

https://docs.particular.net/nservicebus/sagas/

как пример)

https://docs.particular.net/nservicebus/sagas/

Типа бизнесовой шины данных что-то, верно?

зависит от реализации. Скорее что-то вроде аркестрации, если такой термин применим

Про саги лучше у мелкомягких почитать: https://msdn.microsoft.com/en-us/library/jj591569.aspx

И у Джонатана тоже можно немного мыслишек: http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-i-of-ii/

А оттуда по ссылочкам к Уди, Янгу и обмазыванию басами как здесь любят :)

А оттуда по ссылочкам к Уди, Янгу и обмазыванию басами как здесь любят :)

Уди Янгом недоволен. Он предлагает доменные ивенты через синглтон паблишить.

А это зашкварище.

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

А это зашкварище.

А ты вообще знаешь, что такое "зашквар"?

А ты вообще знаешь, что такое "зашквар"?

"херня"

Как кстати решаете обработку доменных событий

В шину пулять их?

Типа медиатора богартовского

Чтобы он через DI обработчики резолвил

Со всякими сервисами, блэкджеком и прочим.

"херня"

Да нет.

Ты поинтересуйся на досуге...

Да нет.

Ну тогда чтобы протестить обработку - надо переопределять регистрации в DI

Хотя...

Их и так надо переопределять)

Просто сервис локатор - такой себе паттерн.

Явное инстанциирование - вообще абсолютное зло.

Как кстати решаете обработку доменных событий

у меня они идут только от команд а диспетчер сам имеет набор обработчиков (симфони в него инжектит их при сборке контейнера)

у меня они идут только от команд а диспетчер сам имеет набор обработчиков (симфони в него инжектит их при сборке контейнера)

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

шо. опять..)