Обзор “Clean Architecture” (Часть II: принципы дизайна модулей и разделения по компонентам)

Рис.1 “Содержание книги и второй части обзора”

Design Principles

Рис.2 “Цели дизайн принципов”
Рис.3 “Принципы дизайна (SOLID)”

SRP: The Single Responsibility Principle

  • accidental duplication — когда код разных акторов зависит от общего модуля, в котором происходят изменения нужные для одного актора, но не другого. Изменения вносятся для одного актора, но влияют сразу на всех
  • merges — когда код разных акторов зависит от общего модуля, в который вносят параллельно изменения нужные как для одного актора, так и для другого. Итоговое поведение может не удовлетворять ни одного из акторов
Рис.4 “Применение принципа SRP на разных уровнях абстракции”

OCP: The Open-Closed Principle

LSP: The Liskov Substitution Principle

ISP: The Interface Segregation Principle

DIP: The Dependency Inversion Principle

Рис.5 “Советы для обеспечения стабильности абстракций”
Рис.6 “Диаграмма классов с применением Dependency Inversion Principle”

Component Principles

Components

Component Cohesion

Рис.7 “Component Cohesion Principles”
Рис.8 “Cohesion principles tension diagram”

Component Coupling

Рис.9 “Component Coupling Principles”
  • Еженедельный билд— билд всей системы раз в неделю. В наше время это кажется уже устаревшим подходом. Надо уметь билдить систему по требованию с той частотой, что нам нужна
  • Устранение циклических зависимостей — по-факту, граф зависимостей должен быть направленным ациклическим графом (directed acyclic graph — DAG). Забавно, что сейчас отсутствие циклов можно контролировать на уровне CI/CD пайплайнов
  • Fan-in: число входящих зависимостей для компонента (сколько компонентов от него зависят)
  • Fan-out: число исходящих зависимостей для компонента (от скольких компонентов он зависит)
  • Fan-in и Fan-out рассчитываются как число классов извне компонентов, которые имеют зависимости на классы внутри компонентов.
  • I (Instability): I = Fan-out/(Fan-out+ Fan-in): эта метрика принимает значения от 0 для полностью стабильного компонента, до 1 — для полностью нестабильного
Рис.10 “Примеры стабильного и нестабильного компонента”
Рис.11 “Правильное размещение стабильных и нестабильных компонент”
  • A: Abstractness. A = Na/Nc
Рис.12 “График Абстрактности и Стабильности и Главная последовательность”
  • Зона боли — здесь у нас полностью стабильные и неабстрактные компоненты. Проблема в том, что если потребуется поменять реализацию, то это будет очень больно
  • Зона бесполезности — здесь у нас абстрактные классы, от которых никто не зависит. Это просто бессмысленно.

--

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Alexander Polomodov

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

More from Medium

Apache Flux: Frictionless STORM topology management — Part 1

Mixins in Common Lisp

Priority Queue — [Introduction to Algorithms]

How to fix Windows 10 Boot Error (Error code : 0xc000000d)