файлом и полями
handler Save() получает данные и отправляет в usecase, там мы пишем логику и отправляем в repository и потом в бд
Суть в чем:
Юзер выполняет 1 действие отправляет форму
А мне нужно выполнить ряд действий
сохранить файл, обработать файл, извлечь из файла, потом используя другие сервисы обработать файл и тд
Все методы вызывать синхронно через функцию Save - нарушу принцип единой ответственности.
так же мне нужно выполнять методы по событию - файл сохранился в директории - сервис такой-то выполняет свою работу
Как я понял мне тут нужен Observer чтоб наблюдать на завершением события и вызывать другое.
или какие есть варианты еще? Брокер сообщений тянуть?
Или есть простое решение?
Add(workCount)... Wait()
Когда будешь дизайнить красивое с точки зрения архитектуры решение, думай о том, что какому-то твоему коллеге придется потом этот код читать и в нем разбираться) И возможно этот коллега будет психопатом маньяком. И возможно у него будет бинзопила..
если назовёшь хендлер вместо save как-нибудь типа HandleUpload, то нарушения принципа не будет)
Здесь проблема не в нарушении мифических принципов единой ответственности, а в возможности частичного отказа. У тебя если синхронно все обработчики в Save вызывать, возможен частичный отказ, и после ответа 500 клиенту, система останется с некорректным стейтом. Например файл записался, но не обработался. Я бы здесь впервую очередь над этим подумал, а не над тем, как оно красиво будет называться, и какие паттерны применять для организации кода
возможно нужен transaction outbox. сохраняешь в бд в 2 таблицы. В первую - саму инфу, во вторую событие, что файл сохранен. В отдельном процессе (горутине) вычитываешь вторую таблицу и делаешь действия нужные, как сделал - удаляешь событие. В таком случае, нет возможности, что приложение где-то упадет не выполнив оставшиеся задачи
+1) Над такой же проблемой сейчас размышляю, у меня есть usecase который обрабатывает успешный платеж, так вот надо придумать, как элегантно управлять транзакциями на уровне usecase))
Так по этому я и думаю над реализацией как параллельно выполнять ряд операций вызывая разные сервисы и после выполнения всех - вернуть юзеру результат тут направшивается Observer
Сам по себе observer лишь инверсирует управление. В том смысле что обработка все равно останься синхронной. Для reliability нужен не просто observer паттерн, а как ты правильно написал брокер, чтобы ретраи можно было навесить и eventually обработать каждый шаг. Но это не про принцип единой ответственности
а ты уже расскидал зависимости классов по принципу open close?
Обсуждают сегодня