Основные строительные элементы "Чистой архитектуры"

Бизнес правила

Бизнес правила - это правила или процедуры, делающие или экономящие деньги. Еще строже говоря, бизнес-правила - это правила, делающие или экономящие деньги независимо от наличия или отсутствия их реализации на компьютере.

Критические правила и данные

• критические - это правила, которые имеют решающее значение для бизнеса
• критические бизнес-данные - это данные, которые используются вне зависимости от автоматизации

Сущности

Сущность - это объект в компьютерной системе, воплощающий небольшой набор критических бизнес-правил, оперирующих критическими бизнес-данными. Он либо содержит бизнес-правила, либо имеет простой доступ к ним. Интерфейс состоит функций, реализующих критические БП.

Варианты использования

Вариант использования - это объект, который описывает бизнес-правила, которые должны выполняться в рамках автоматизируемой системы. Он состоит из "входных данных", "выходных данных" и порядка действия.

Варианты использования управляют действиями сущностей

По описанию варианта использования нельзя сделать вывод об архитектуре и деталях реализации автоматизированной системы.

Вариант использования - это способ сделать из всех людей "пользователей", так как протаскивает в бизнес правила чисто технические понятия. К которым уже все привыкли.

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

Модели запросов и ответов

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

Проблема водопадных подходов

Основная проблема построения бизнес-правил - пользователь достаточно хорошо представляет критические правила и очень плохо варианты использования. Поэтому нужно использовать итерационные подходы, когда новые решения пользователь принимает на основе промежуточных реализаций. Это одна из причин успеха Agile.

Политики и уровни

Бывает очень сложно понять о каких уровнях говорит Роберт Мартин. Согласно "чистой архитектуры" программные системы - это направленная обработка данных, когда входные данные обрабатываются политиками и передаются на выход программы. Отсюда у нас есть два важных понятия:

Политика - набор правил обработки данных на каждом этапе

Уровень - это степень удаленя от "ввода" и "вывода".

Политики управляющие вводом и выводом являются самыми низкоуровневыми в системе. В примерах Роберт Мартин рассматривает в основном ввод и вывод - как устройства, отсюда прослеживается монолитность "чистой архитектуры" и ее расположенность на самом низком уровне проектирование - уровне кода. Скорее всего речь идет об аппаратном вводе и выводе, так как с позиции обработки данных "ввод" и "вывод" есть абсолютно у любой абстракции.

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

Основное предположение, которое делает Роберт Мартин - абстракции более высокого уровня меняются реже, чем абстракции более низкого уровня, поэтому они являются более устойчивыми (!). Если критические бизнес-правила меняются постоянно (стартапы и т.д.), то проектирование на уровне кода становится неэффективным. В таких случаях инфраструктурная часть (фреймворки) стабилизируют ситуацию.

Так же выгодно использовать проектирование от интерфейса и API, так как это позволяет "утрясти" бизнес-логику до приемлимого уровня.

Презентаторы и скромные объекты

Скромный объект - это вариант реализации одноименного шаблона проектирования. Он первоначально создавался для упрощения автоматизированного тестирования, так сложные для тестирования части выносились в "скромный объект", который должен быть максимально простым и тем самым понятным для поиска ошибок аналитическим способом. Второй объект содержит всю сложную логику, которая поддается тестированию.

В рамках "чистой архитектуры": "презенторы" - это легко тестируемый объект, а view - это "скромный" объект. Презенторы должны выдавать простые, максимально плоские структуры во View, используя для этого ViewModel

Главный компонент

Когда у нас есть набор компонетов - "кирпичиков", каждый из которых реализует свою логику на нужном уровне абстракции, то возникает необходимость создать и настроить работу всех компонентов друг с другом. Это делается с помощью "Главного компонента" - Main.