Чистая архитектура. Часть 2

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

Глава 12. Компоненты

Коротко:

  • Компонент — наименьшая сущность, которую можно задеплоить, как часть системы.
  • Компоненты, DLL — плагины к бизнес‑правилам.

Глава 13. Связность компонентов

Коротко — чтобы определить, к какому компоненту относится тот или иной класс, следует пользоваться 3 принципами:

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

Принцип эквивалентности переиспользования

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

Принцип общей причины для изменения

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

Принцип совместного переиспользования

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

Глава 14. Сочетаемость компонентов

Коротко — чтобы определить отношения между компонентами, следует пользоваться 3 принципами:

  • принцип ацикличности зависимостей;
  • принцип стабильных зависимостей;
  • принцип стабильности абстракций.

Принцип ацикличности зависимостей

Не допускайте зацикленности в графе зависимостей компонента. Если в зависимостях есть цикл, его можно разорвать одним из 2 способов:

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

Принцип стабильных зависимостей

Зависимости должны быть направлены в сторону устойчивости. Некоторые компоненты должны быть более изменяемыми, чтобы удовлетворять изменения в бизнес‑требованиях. И такие менее стабильные компоненты должны зависеть от более стабильных.

Чтобы узнать, насколько компонент нестабилен, можно посчитать количество входных и выходных зависимостей.

Нестабильность = Кол‑во выходных / (Кол‑во входных + Кол‑во выходных)

Принцип стабильности абстракций

Компонент должен быть настолько же абстрактным, насколько он стабилен.

Абстрактность = Кол‑во абстрактных классов и интерфейсов в компоненте / Общее количество классов в компоненте

По оси Х — нестабильность, по оси Y — абстрактность. Следует придерживаться линии main sequence и избегать зон по углам:

Глава 15. Что такое архитектура

Коротко:

  • Цель хорошей архитектуры — облегчить разработку, деплой и поддержку системы.
  • Хорошая архитектура выделяет бизнес‑логику и считает её важнейшим элементом системы.
  • Хорошая архитектура пытается построить систему так, будто количество непринятых решений относительно деталей — максимально.

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

Каждая система может быть разбита на две части: бизнес‑логика и детали реализации. Детали говорят, как пользователи, компоненты и т. д. общаются с бизнес‑логикой. Хорошая архитектура выделяет бизнес‑логику и считает её важнейшим элементом системы, делая её независимой от деталей реализации.

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

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

Глава 16. Независимость

Коротко — архитектура должна поддерживать:

  • юзкейсы;
  • поддерживаемость;
  • разработку;
  • лёгкий деплой системы.

Мы не знаем заранее всех юзкейсов, организацию команды разработки, требования к деплою и т. д. А даже если бы и знали, то они всё равно бы менялись во время жизни системы. Хорошая архитектура позволяет вносить изменения дешевле.

Следует делить систему на слои. Например:

  • независимые бизнес‑правила;
  • бизнес‑правила под конкретно это приложение;
  • пользовательский интерфейс;
  • база данных и др.

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

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

Разделять систему можно по‑разному:

  • на уровне исходников;
  • уровне развёртывания;
  • и сервисном уровне.

Какой способ подходит, зависит от самого проекта, стадии, на которой он находится и других параметров.

Глава 17. Границы

Коротко:

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

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

Границы должны отделять сущности, которые имеют значение (для бизнес‑логики) от тех, которые не имеют значения. Например, бизнес‑логика не должна зависеть ни от схемы БД, ни от языка запросов.

В хорошей архитектуре бизнес‑логика — это основа, а всё остальное: устройства ввода‑вывода, БД и т. д. — плагины к ней:

Что дальше?

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

← Самое важное в самокопании Время для чтения есть всегда — 2 →