Чистая Архитектура

Архитектура не зависит от существования какой-либо библиотеки.

Это позволяет вам использовать фреймворк как инструмент, а не загонять вашу систему в рамки ее ограничений.

Тестируемость .

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

независимость пользовательского интерфейса .

Пользовательский интерфейс можно легко изменить, не меняя остальную часть системы.

Например, веб-интерфейс можно заменить консольным без изменения бизнес-правил.

Независимость базы данных .

Вы можете обменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще.

Ваши бизнес-правила не связаны с базой данных.

Независимость от любого внешнего сервиса .

На самом деле ваши бизнес-правила просто ничего не знают о внешнем мире.

Диаграмма в начале статьи — это попытка объединить все эти идеи в одну эффективную диаграмму.

В общем, чем дальше вы идете, тем более общим становится уровень.

Внешние круги — механика.

Внутренние круги — это политика.

Главное правило, благодаря которому эта архитектура работает: Правило зависимости .

Это правило гласит, что зависимости в исходном коде могут указывать только внутрь.

Ничто во внутреннем круге не может ничего знать о внешнем круге, ничто во внутреннем круге не может указывать на внешний круг.

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

Мы не используем ничего из внешнего круга, что могло бы повлиять на внутренний.

Сущность может быть объектом с методами или коллекцией структур данных и функций.

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

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

Они инкапсулируют наиболее распространенные правила высокого уровня.

Они менее всего подвержены изменениям из-за каких-либо внешних изменений.

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

Внешние изменения не должны влиять на уровень сущности.

Он инкапсулирует и реализует все варианты использования системы.

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

Сущности для реализации бизнес-правил.

Мы не ожидаем, что изменения в этом слое повлияют Сущности .

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

Этот слой изолирован от подобных проблем.

Однако мы ожидаем, что изменения в приложении повлияют Сценарии .

Если в поведении приложения произойдут какие-либо изменения, они, несомненно, отразятся на коде этого слоя.

Сценарии И Сущности , в формат, наиболее удобный для дальнейшего использования, например в базе данных.

Например, именно этот уровень будет полностью содержать архитектуру MVC. Модели скорее всего, это структуры данных, которые передаются от контроллеров к Сценарии а затем обратно из Сценарии К Взгляды .

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

Код внутри этого круга не должен ничего знать о базе данных.

Это слой скопления деталей.

Интернет — это деталь, база данных — это деталь, мы храним эти вещи снаружи, чтобы уменьшить их влияние.

Вы можете решить, что вам нужно больше, чем эти четыре.

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

Тем не менее, Правило зависимости всегда применяется.

Зависимости в исходном коде всегда указывают внутрь.

По мере продвижения внутрь уровень абстракции возрастает. Внешний круг — уровень детализации.

Внутренний круг является наиболее распространенным.

Контроллеры И Представление взаимодействовать с Сценарии из следующего слоя.

Обратите внимание на поток управления.

Это начинается в Контроллер , проходит через Сценарий а затем завершает выполнение в Подчинение .

Обратите внимание на зависимости в исходном коде.

Каждый из них указывает внутрь себя.

Сценарий .

Обычно мы разрешаем это кажущееся противоречие путем Принцип инверсии зависимостей .

Например, предположим, что из Сценарии нужно связаться Подчинение .

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

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

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

Вы можете использовать базовые структуры или, если хотите, объекты передачи данных (DTO — это один из шаблонов проектирования, используемых для передачи данных между подсистемами приложения).

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

Или вы можете упаковать его в хеш-таблицу или объект. Важно, чтобы передаваемые структуры данных были изолированы при передаче через границы.

Мы не хотим обманывать и переносить Сущность или строки базы данных.

Мы не хотим, чтобы структуры данных имели какие-либо зависимости, нарушающие Правило зависимости .

Например, многие платформы (ORM) возвращают данные в удобном формате в ответ на запрос к базе данных.

Мы могли бы назвать это RowStructure. Мы не хотим пропускать эту структуру через границу.

Это было бы нарушением Правила зависимостей потому что в этом случае внутренний круг получает информацию о внешнем круге.

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

Разделив программное обеспечение на слои и следуя Правило зависимости вы создадите тестируемую систему со всеми вытекающими отсюда преимуществами.

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