Избегайте неиспользуемых сценариев в многоуровневой архитектуре

В многоуровневых архитектурах принято создавать классы, называемые Use Cases (“сценариями использования”). Эти классы содержат отдельные логические единицы, которые можно тестировать изолированно, составлять вместе для создания более сложной логики, и часто являются наиболее важной частью архитектуры приложения. Казалось бы, все пути кода должны проходить через Use Case, но на самом деле иногда бывает полезнее их пропустить.

Неиспользуемый сценарий (Useless Case)

Если каждый кусок кода должен включать в себя Use Case, то в кодовой базе окажется некоторое количество бесполезных или «неиспользуемых» сценариев, то есть Use Case, которые не делают ничего, кроме как пропускают поток через себя. Это распространенная проблема в приложениях, которые в основном основаны на CRUD. В этом случае почему бы не подойти к проблеме с точки зрения YAGNI — You Aren’t Going to Need It!

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

Пример

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

class GetTaskListUseCase(
  private val taskRepository: TaskRepository,
) {
  operator fun invoke(): List<TaskItem> {
    return taskRepository.getTaskItems()
  }
}

Этот Use Case ничего не дает, это просто пустой код. Здесь нечего тестировать, и вы можете просто вызвать taskRepository.getTaskItems() напрямую. Так что этот класс можно удалить. Вуаля! Меньше кода для поддержки и управления. В будущем, если требования изменятся, вы сможете добавить этот сценарий использования обратно, но вы не застрянете с ним, если эти изменения никогда не произойдут.

Заключение

Надеюсь, это показывает ценность удаления бесполезных примеров из кодовой базы. Как всегда, это следует делать с осторожностью и при поддержке владельцев кодовой базы. Некоторым командам нравится постоянство, когда сценарии есть для всего, даже если они не нужны. Я работал над проектами, в которых использовались оба подхода, и в каждом случае код был просто прекрасным, если не слишком многословным в некоторых случаях. Попробуйте и посмотрите, какой стиль лучше работает в каждом конкретном случае.

Источник