#arch #solid #sold4mens #note
Принцип стабильных абстракций - The Stable Abstraction Principle или SAP

Стабильные пакеты абстрактны. То есть абстрактность должна возрастать со стабильностью. Стабильность здесь — то, как часто нам приходится менять части пакета: классы, интерфейсы, или что-либо ещё. Абстрактные пакеты должны быть стабильны, чтобы безболезненно на них завязываться.

А вот гибкие пакеты, наоборот, конкретны — они должны быть нестабильны, чтобы мы их легко меняли. Все наши приложения, наши конечные пакеты — это на самом деле очень нестабильные составляющие, которые зависят от множества всего и ломаются чаще, чем пакеты, от которых они зависят.

❓ Можно ли измерить абстрактность?

Да. Абстрактность — это число абстрактных классов и интерфейсов в пакете, деленное на общее число классов и интерфейсов в этом самом пакете.

#arch #solid #solid4mens #note
Принцип ациклических зависимостей - The Acyclic Dependencies Principle или ADP

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

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

Другой пример: вы написали "Модуль Б", который зависит от "Модуля А" и использует функции "Модуля В". "Модуль В" в свою очередь зависит от "Модуля А". Если вы или ваши коллеги внесут изменения в "Модуль Б", то эти изменения затронут "Модуль В", а он затронет код "Модуля А", который затронет код "Модуля Б"... и начнется типичная дилемма курицы и яйца. 🤯

Следование принципу ADP решает эту дилемму и другие проблемы:

1️⃣ Сложность тестирования и обслуживания компонентов системы;

2️⃣ Циклические ссылки на классы создают высокую степень связи; оба класса должны перекомпилироваться каждый раз, когда любой из них изменяется;

3️⃣ Объекты с очень большим количеством циклических ссылок часто являются объектами-богами. Даже если это не так, они имеют тенденцию приводить к спагетти-коду.

* на постере пример системы с циклическими зависимостями.

#exp #arch #grasp
Проектирование пакетов/компонентов системы

На ряду с принципами SOLID, Роберт Мартин описал также 6 других:

1️⃣ Принцип эквивалентности повторного использования и выпуска (Reuse-Release Equivalency Principle или REP);

2️⃣ Общий принцип закрытия (Common Closure Principle или CCP);

3️⃣ Общий принцип повторного использования (Common Reuse Principle или CRP);

4️⃣ Принцип ациклических зависимостей (Acyclic Dependencies Principle или ADP);

5️⃣ Принцип стабильных зависимостей (Stable Dependencies Principle или SDP);

6️⃣ Принцип стабильной абстракции (Stable Abstraction Principle или SAP).

Возможно, вы уже слышали рекомендацию, в которой говорится, что мы должны стремиться к достижению low coupling (низкой связанности) и high cohesion (высокого сцепления) при работе над кодовой базой.
Мне не нравится термин "сцепление", поэтому я буду использовать слово "сплоченность".

❗️ Coupling (связанность) представляет собой степень взаимосвязи между блоками. Другими словами, это количество соединений между двумя или более блоками. Чем меньше число, тем ниже coupling. Блок (юнит) здесь необязательно является классом. Это может быть метод, класс, группа классов или даже модуль.

Понятие Cohesion (сплоченность) мы разберем чуть позже, когда узнаем о принципах REP, CCP, CRP. Для удобства эти принципы разделяют на следующие группы:

1️⃣ Принципы связности пакетов/компонентов - REP, CCP, CRP - снижают степень связности (coupling) пакетов и компонентов;

2️⃣ Принципы сплоченности пакетов/компонентов - SAP, SDP, ADP - увеличивают степень сплоченности (cohesion).

* На постере идеальный пример сплоченности модулей и сцепления компонентов.

#arch #note #solid4mens #solid
Принцип эквивалентности повторного использования и выпуска - The Reuse-Release Equivalency Principle или REP

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

❗️ Эффективное повторное использование требует отслеживания релизов в системе контроля изменений

Автору библиотеки необходимо идентифицировать выпуски по каким-либо номерам или названиям. Это позволяет пользователям библиотеки идентифицировать разные версии. Это требует использования какой-то системы отслеживания релизов.

❗️ Единица повторного использования равна единице выпуска.

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

Пакет — это эффективная единица повторного использования и выпуска.

#arch #note #solid4mens #solid
Общий принцип закрытия - The Common Closure Principle или CCP

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

Этот принцип представляет собой переформулировку принципа единой ответственности (SRP), рассмотренного в SOLID , путем применения его к компонентам. Точно так же, как SRP утверждает, что у класса не должно быть более одной причины для изменения, CCP утверждает, что у компонента не должно быть более одной причины причины для изменения.

❗️ Когда необходимо внести изменения в код, идеально, чтобы эти изменения происходили только в одном компоненте, а не в нескольких.

#arch #note #solid4mens #solid
Общий принцип повторного использования - The Common Reuse Principle или CRP

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

Также CRP указывает, какие классы не должны быть объединены. Когда один компонент использует другой, между ними возникает зависимость. Даже если использующему компоненту нужен только один класс из используемого, это не уменьшает зависимость. Поэтому, когда происходит изменение в используемом компоненте, обычно требуются соответствующие изменения в использующем компоненте.

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

❗️ Компонент не должен зависеть от того, что ему не требуется.

#arch #solid #note #solid4mens
Диаграмма противоречий для определения связности компонентов

Три принципа связности компонентов вступают в противоречие друг с другом:

1️⃣ Принципы эквивалентности повторного использования (REP) и согласованного изменения (CCP) являются включительными: оба стремятся сделать компоненты как можно крупнее.

2️⃣ Принцип повторного использования (CRP) — исключительный, стремящийся сделать компоненты как можно мельче. Задача хорошего архитектора — разрешить это противоречие.

Диаграмма противоречий, показывающая, как три принципа связности влияют друг на друга. Ребра на диаграмме описывают цену нарушения принципа на противоположной вершине.

❗️ Архитектор, уделяющий внимание только принципам REP и CRP, обнаружит, что простое изменение вовлекает слишком большое количество компонентов. С другой стороны, архитектор, уделяющий особое внимание принципам CCP и REP, вынужден будет выпускать слишком много ненужных версий.

❗️ Хороший архитектор найдет в этом треугольнике противоречий золотую середину, отвечающую текущим нуждам разработчиков, а также подумает об изменениях, которые могут произойти в будущем. Например, на ранних этапах разработки проекта принцип CCP намного важнее, чем REP, удобство разработки важнее удобства повторного использования.

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

#exp #arch #case
Хочу поделиться кейсом задачи, которую недавно решил в Github Booster. Цель - продемонстрировать, как можно развивать отдельные модули, как можно мыслить, чтобы дать импульс такому развитию.

📌 Задача

1️⃣ Использовать два кейса - syncSubscribers и syncSubscriptions для подписки на пользователей, которые подписались на целевого пользователя в Github, но на которых я не подписался в ответ.

2️⃣ Использовать два кейса - syncSubscribers и syncSubscriptions для отписки от пользователей, на которых подписался целевой пользователь, но которые не подписались на меня в ответ.

Процесс развития модулей

▶️ Уровень 1

Нарушен принцип SRP - класс SyncManager может изменяться более чем по одной причине. Декомпозируем.

▶️Уровень 2

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

▶️ Уровень 3

Все, что хотели, разделили и абстрагировали. И тут возникла циклическая зависимость, которая порождается методами subscribersBalancing и subscriptionsBalancing. SubscribersManager класс зависит от SubscriptionsManager и наоборот.

▶️ Уровень 4

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

Cоздаю интерфейсы SubscribersSyncManagerInterface и SubscriptionsSyncManagerInterface, чтобы Manager классы завязывались на них (выделены зеленым).

Эти интерфейсы в моем случае ведут к еще одним Manager классам, которые нужны для отдельной логики.

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

Плюсы и минусы

➕ Соблюдается принцп SRP;
➕ Есть Handler классы, которые удобно покрывать тестами;
➕ Через Dependency Injection можно переопределять детали реализации интерфейсов.

❌ Много классов;
❌ Структура проекта без конкретных правил может стать чрезмерно запутанной.

#arch #fsd #note
Дизайн с нарезкой деталей - Feature-Sliced Design или FSD

❗️ Feature-Sliced Design (FSD) — это архитектурная методология для проектирования frontend-приложений. Проще говоря, это свод правил и соглашений по организации кода. Главная цель методологии — сделать проект понятным и структурированным, особенно в условиях регулярного изменения требований бизнеса.

Проект на FSD состоит из слоев (layers), каждый слой состоит из слайсов (slices) и каждый слайс состоит из сегментов (segments).

❗️ Слои

Слои стандартизированы во всех проектах и расположены вертикально. Модули на одном слое могут взаимодействовать лишь с модулями, находящимися на слоях строго ниже. На данный момент слоев семь (снизу вверх):

1️⃣ shared - переиспользуемый код, не имеющий отношения к специфике приложения/бизнеса.

2️⃣ entities - бизнес-сущности.

3️⃣ features - взаимодействия с пользователем, действия, которые несут бизнес-ценность для пользователя.

4️⃣ widgets - композиционный слой для соединения сущностей и фич в самостоятельные блоки.

5️⃣ pages - композиционный слой для сборки полноценных страниц из сущностей, фич и виджетов.

6️⃣ processes (процессы, устаревший слой) - сложные сценарии, покрывающие несколько страниц.

7️⃣ app - настройки, стили и провайдеры для всего приложения.

❗️ Слайсы

Затем есть слайсы, разделяющие код по предметной области. Они группируют логически связанные модули, что облегчает навигацию по кодовой базе. Слайсы не могут использовать другие слайсы на том же слое, что обеспечивает высокий уровень связности (cohesion) при низком уровне зацепления (coupling).

❗️ Сегменты

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

#highloadpp #video
Всем привет 👋

Недавно наткнулся на интересный доклад одного из спикеров HighLoad++ о паттернах отказоустойчивой архитектуры. Доклад очень интересный и, что самое важное, практичный. Автор рассказывает про распространенные решения, и, если вы с ними никогда не сталкивались, то самое время ознакомиться хотя бы в теории.

https://youtu.be/WWTq-tbZwUE?si=52nSg02EIUDFlGCJ

#arch #ddd
Предметно-ориентированное проектирование - (The Domain-Driven Design или DDD)

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

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

1️⃣ чаще возникает путаница в требованиях;

2️⃣ сложно поддерживать аналитические артефакты, которыми пользуется заказчик и разработчики;

3️⃣ появляется устаревшая документация, которая может вводить в заблуждение новых разработчиков;

4️⃣ появляется много лишнего кода.

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

❗️ Предметно-ориентированное проектирование - это методология, которая предлагает последовательный алгоритм проектирования бизнес моделей системы и её бизнес правил.

В рамках этой методологии мы рассмотрим:

1️⃣ Как бизнес модель и её правила могут влиять на архитектуру приложения;

2️⃣ Принципы, формирования единого языка, на котором говорят все участники проекта;

3️⃣ Процессы эффективной дистилляции знаний о модели и её правилах.

#arch #ddd
Модель предметной области

❗️ Модель предметной области - это упрощение; это такая интерпретация реальности, при которой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются. Каждая модель должна представлять определенный аспект или какую-либо идею, представляющую интерес.

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

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

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

Основные принципы использования модели при разработке:

1️⃣ Модель и архитектура программы должны взаимно определять друг друга. Именно тесная связь модели и её реализации определяют важность и нужность самой модели, а также гарантирует, что проделанный анализ модели отражен в её реализации - в программе;

2️⃣ Модель лежит в основе языка, на котором говорят все участники проекта. Благодаря связи модели с её реализацией разработчики могут обсуждать все связанные с программой вопросы на этом языке и общаться со специалистами предметной области без переводчика;

3️⃣ Модель - это дистиллированое знание. Она отображает только аспекты и идеи, представляющие наибольший интерес. Модель не должна содержать бесполезные или вторичные детали, знание которых не приносит существенной пользы.

#ddd #arch
Единый язык - Ubiquitous Language

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

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

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

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

Объем требуемого перевода и риск неправильного понимания - слишком высокая цена для проекта.

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

Язык на основе модели должен использоваться среди разработчиков для описания не только объектов системы, но и для задач и функциональных возможностей. Одна и та же модель должна давать разработчикам и специалистам-предметникам язык общения друг с другом, а также позволять специалистам обсуждать между собой вопросы технических требований, планирования разработки, функциональных возможностей. Чем шире единый язык в проекте, тем легче наладить плодотворное общение между его участниками.

#arch #ddd
Связь между моделью и реализацией

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

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

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

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

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

#arch #ddd
Модель, выраженная в программе
Чтобы суметь найти компромиссы в программной реализации и при этом не по­терять преимуществ проектирования по модели, связь между моделью и реализацией необходимо прорабатывать на уровне деталей.
В эти детали входят: ассоциации, сущности, объекты значений, службы, модули.

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

Ассоциации
❗️Ассоциации - способ связать объекты, отношения БД и компоненты. Для всякой прослеживаемой в модели ассоциации должен существовать механизм в программе. Например, внешние ключи БД, агрегаты и тд.

Существует как минимум три способа сделать ассоциации более удобными и управляемыми:

1️⃣Свести отношения к однонаправленным, прослеживаемым в одном направлении.

2️⃣Добавить квалификаторы, тем самым явно ограничивая ассоциацию. Например, от "один ко многим" до "один к одному"

3️⃣Устранить несущественные ассоциации. Например, избавиться от транзитивных зависимостей.

❗️Важно ограничить взаимосвязи до минимума. Двунаправленные ассоциации означа­ют, что два объекта можно понять только совместно, как одно целое. Если техническое задание непосредственно не требует двунаправленных отношений, то сведение их к однонаправленным снижает взаимозависимость и упрощает струк­туру программы (соблюдается принцип low coupling).