эликсире
подумал как это скажется на подходе к написанию кода
пришел к выводу что к примеру у нас есть модуль который шлет письма по каким-то входным данным
так вот если мы топим за чистые функции - то должен быть модуль который собирает эти самые письма - функции этого модуля будут чистыми так как ничего не куда не шлет а по сути собирают структурку
далее мы эту структурку передаем в какой-нибудь Mailer.deliver(email) - который легко заменяется в тестовом окружении - у Swoosh даже есть тестовый адаптер - так что работа сделана за нас
что я все еще не понимаю - так если у меня три разных письма собираются в зависимости от переданных данных - но я все еще не хочу в своем бизнес коде проверять эти три случая - мне все равно приходится мочить мой модуль Notifications
что я опять делаю не так и что упускаю?
Именно так и сделано в Bamboo, у тебя есть композиция, которая чистая и детерминирована, а есть Sender который как раз сайдэффекты генерирует
Это называется repository паттерн. Когда для взаимодействия с внешним миром есть только один интерфейс (Repo), с грязной имплементацией Так, например, работает эликсировский Ecto: все операции, валидации и структуры строятся чисто, а потом один раз вызывается Repo. Даже транзакции чаще всего строятся как набор запросов через Ecto.Multi, а потом один раз вызывается Repo.transaction Это позволяет легко подменить интерфейс на чистый мок, и локализовать весь грязный код в одном месте
Обсуждают сегодня