там всё становится не очень красиво когда появляются callable

module ActivityMonitoring
  module Notifiers
    class Slack
      def self.call(...)
        new(...).call(...)
      end

      def self.notify(...)
        ::SlackNotifier.notify(...)
      end

      def initialize(slack_notifier: self.class.method(:notify), **)
        @notifier = slack_notifier
        super()
      end

      def call(data: {}, **)
        data.each do |group_by, by_group_by|
          text = message(group_by, by_group_by)

          @notifier.call(text: text, channel: '#some_channel') if text.present?
        end
      end
      
      #omited

    end
  end
end

module ActivityMonitoring
  module Notifiers
    class Slack
      def self.call(...)
        new(...).call(...)
      end

      def self.notify(...)
        ::SlackNotifier.notify(...)
      end

      def initialize(slack_notifier: self.class.method(:notify), **)
        @notifier = slack_notifier
        super()
      end

      def call(data: {}, **)
        data.each do |group_by, by_group_by|
          text = message(group_by, by_group_by)

          @notifier.call(text: text, channel: '#some_channel') if text.present?
        end
      end
      
      #omited

    end
  end
end

Нормально, не вижу уродств) Разве что можно вместо извлечения метода в объект лямбду с явным вызовом передавать, чтобы кликабельно было

тут 3rd party API вынесен в DI
что бы в тестах не заморачивать с его моками

у меня RubyMine и так всё правильно по клику на self.class.method(:notify) показывает)
наверное не самый красивый способ это пихать в singleton_class, поэому и сказал что можно воспользоваться контейнерами
но всегда можно создать callable класс/модуль и передавать его def initialize(notifier: SlackNotifier)

Вот контейнеры точно некликабельные :(

Или можно сделать плагин к иде? Может уже кто-то сделал?

это я больше про идиоматичность, типа "с какого черта default implementation лежит в singleton class?", получается что сам singleton_class выступает как контенер зависимостей  с уже подсунутой реализацией. а сам injection осуществляется на уровне конструктора инстанса (что правильно)

конечно, всегда можно создать вложенные модули module Implementation::SlackNotifier с единственным методом self.call и тогда у инстанса будет def initialize(notifier: Implementation::SlackNotifier)
вроде как красиво и SRP соблюдается на всех уровнях
но мы решили что нам и так сойдет =)
типа соглашение - singleton_class хранит дефолтные реализации DI зависимостей для инстанса

Nemo @vveare138 @davydovanton https://gist.github.com/IvanShamatov/e5db7f936ecf80bb7ba2ffdaee7d7712

вот это можно считать каноничным репо?

Я у себя нечто похожее и сделал (о чём где-то выше писал), но были сомнения о том, ок это или не ок. Елинственное, что по итогу я не вызывал один метод репозитория, а несколько (для конечного досутпа к релейшену)

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

не совсем, он возвращает датасет

ага, верно

т.е. to_a надо в конце метода for_dashboard

да

Я бы модель через конструктор прокидывал бы и вместо миксинов наследование бы сделал. А в целом круто, мне нравится 👍

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

а, я понял

ну да, чет я забыл про дефолтное значение