Ортодоксальный Backend

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

"Мы" как минимум задумываемся не лучше ли будет использовать MVVM в той или иной ситуации :)

Репозиторий с точки зрения ООП это по сути тот же контроллер — тот же набор методов, только уже не для обработки запросов, а для работы с хранилищем.

Это гейтвей а не репозиторий. Репозиторий это коллекция доменных моделей.

При использовании именно репозитория, выборки данных для отдачи на клиент, например, будут в гейтвее(возвращать dto/структуры)

Ну и MVC все же не про структуру папок, и то что в вебе называют MVC на самом деле является Model-View-Adapter(контроллер=адаптер, а в MVC контроллер не должен знать про представление)

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

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

Но контроллер вообще не должен быть классом, это должен быть скорее модуль

class ListInvoices

  def initialize(invoice_repository)
    @repository = invoice_repository
  end

  def call
    @repository.get_all
  end
end

module ListInvoices

  def self.call(repository)
    repository.get_all
  end
end

Почему тогда в примере не сделать контроллер модулем?

//let repository, mail_service, request_params;
// ...
const context = {repository, mail_service, request_params};
// ...
function listInvoices({repository}) {
  repository.getAll();
}

Зачем ему стейт?

Хорошо, вместо контроллера теперь есть набор «функций» для доступа к модели, которые, кстати, тоже можно структурировать, используя каталоги файловой системы, например.

сторонник практики инверсии зависимостей (Dependency Inversion, D в SOLID). Поэтому подобные зависимости мне нужно инициализировать где-то снаружи и передавать в конструктор контроллера.

# Плохо (инициализируем зависимость в конструкторе)

Но мы пойдём дальше и реализуем паттерн Unit of Work

Здесь возникает ощущение дежавю, как и с контроллерами: а не является ли репозиторий такой же рудиментарной сущностью? Забегая наперёд, отвечу — да, является.

То есть, мы можем отказаться от Repository и Controller в пользу единого унифицированного Action!

def initialize(attrs, payment_service)

Поэтому в рамках фреймворка Dandy я реализовал роутер