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

В этом стриме рассмотрим следующие вопросы:

• Разница между дизайном и архитектурой
• Влияние дублирования на работу программистов
• Проблемы применения SOLID
• Проблемы повторного использования
• Принцип устойчивости зависимостей и абстракций
• Важность границ
• Кричащая архитектура
• Чистая архитектура

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

Это очень спорное утверждение, которые требует уточнения нескольких вещей:

• Дизайн - это часть архитектуры, но архитектура охватывает куда больше чем дизайн
• Архитектура объединяет все аспекты существования программного обеспечения (требования, принципы, цели, задачи и т.д.)
• Дизайн определяет только то, что будет выражено кодом и структурой приложения (например, дизайн не ответит на вопрос "Какие требования есть у проекта")
• Цель архитектуры сильно шире, чем только упрощение сопровождения, цель архитектуры - это баланс.

Архитекторы часто попадают в ловушку, зависящую от их страха перед дублированием

Дублирование бывает:

• истиным - когда изменение в одной части всегда требует изменения всех других "похожих" частей
• ложным - когда изменения могут идти разными путями

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

При тиражировании создаются копия исходного кода, но при изменении в исходном коде (обновлении версии), в скопированных участках требуется сначала подготовить окружение, а только потом проводить изменения.

Чем больше разрыв между изначальным и тиражируемым кодом, тем больше может быть лаг по времени по внесению изменений. Таким образом "истиное" дублирование, может позволять организовать работу большого числа команд, с разбежкой по версиям.

Роберт Мартин придумал замечательные принцип, которые легли в аббревиатуру SOLID (сама аббревиатура придумана Майклом Фэзерсом). Эти принципы являются чуть ли не основой любого разговора о дизайне кода, но у них есть большая проблема - они очень абстрактны, а значит трактуются разными людьми по-разному.

Например, у принципа единственной ответственности есть аж три популярные трактовки:

• У модуля должна быть только одна причина для изменения;
• У модуля должна быть только одна обязанность;
• У модуля должен быть только один вектор развития.

На самом деле все становится проще, если ввести ряд принципов, которые формулируются сильно проще:

• Single Responsibility - старайся делать модули как можно меньше
• Open Closed - старайся делать модули расширяемыми по вектору развития, и не расширяемыми по другим причинам
• Liskov Substitution - наследуй редко, наследуй строго по принципу "является"
• Interface Segregation - создавай и минимизируй интерфейсы
• Dependency Inversion - используй интерфейсы, вместо реализаций

Основная проблема SOLID - он преувеличивает значимость зависимостей и управляет в основном ими. Что сильно "дробит" и тем самым усложняет код.

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

В "Чистой архитектуре" для решение этой проблемы используется два принципа:

• Принцип устойчивых зависимостей - зависимости должны быть направлены в сторону устойчивости. Т.е. зависисмостями (повторно используемым кодом) могут быть только устойчивые компоненты, в противном случае стоит подумать о дублировании.
• Принцип устойчивости абстракции - устойчивость компонента пропорциональна его абстрактности. Т.е. чем "специфичнее" компонент, тем сложнее его использовать повторно, не создавая риска "неожиданного поведения" при изменениях. Поэтому повторно могут использоваться компоненты которые меняются редко, например, визуальные компоненты - списки, деревья, кнопки и т.д.

Границы необходимы для нескольких целей:

• организационные (каждый должен иметь свою зону ответственности, определенную границей)
• черный ящик (чем меньше деталей мы знаем, тем лучше)
• отделение значимого, от незначимого (в один момент времени мы можем сосредоточиться только на чем-то одном)
• разделение постоянных частей и временных (постоянные - ядро, бизнес-логика, GUI - временные решения)
• зоны развертывания.

Границы нужны чтобы их пересекать, для этого вводятся правила (интерфейсы) взаимодействия. На уровне кода - это способность через интерфейс обратиться к функциям за пределами границы. Границы который нельзя пересекать - это демилитаризованные зоны, пересечение таких границ делается по "шлюзовому" принципу - сторона А положила данные в шлюз, заблокировала шлюз, сторона Б открыла шлюз со своей стороны и забрала данные.

В монолите тоже есть границы, но зона развертывания едина.

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

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

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