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

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

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

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

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

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

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

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

#arch #ddd
Модули (Module)

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

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

Как и все остальное в искусстве DDD, Модули являются механизмом коммуникации. <...> Если вы помещаете несколько классов в один Модуль, вы тем самым гово­рите вашему преемнику, которому предстоит изучать эту архитектуру: думай о них вместе, как о целом. Если ваша модель рассказывает историю, то Модули - это ее главы.

Эрик Эванс

При проектировании Модулей придерживайтесь следующих правил:

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