Отличная книга, которую должен прочитать и изучить каждый разработчик ПО!
Что такое Архитектура ПО? Что такое ХОРОШАЯ архитектура ПО? Основные принципы и способы их реализации. Что НЕЛЬЗЯ рассматривать как часть архитектуры, и какие решения следует максимально отложить?
Я подготовил серию ментальных карт, посвященных книге «Чистая Архитектура» дяди Боба (Роберта Мартина):
Вы знаете, что База Данных - это “деталь”? Неважная второстепенная низкоуровневая необязательная функция, которой можно пренебречь при проектировании архитектуры!
Вы знаете про Веб тоже самое? Это просто неважное устройство ввода-вывода, которым также следует пренебречь при проектировании архитектуры!
А как насчет фреймворков? То же самое. Не женитесь на своём фреймворке. Используйте безопасный, а еще лучше - удаленный секс. 🤣
Несколько примеров того, как похожие архитектуры могут приводить или не приводить к проблемам. И что использовать, чтобы избежать проблем (спойлер: Инкапсуляцию)
Все вышеперечисленное и краткий недостающий совет…
Вобщем, отличная информация! Все подробности в моих ментальных картах:
Пятая часть книги содержит МНОГО полезной информации:
Что такое архитектура ПО? Какие типы взаимозависимостей могут существовать? Как провести границы между компонентами? Какие типы границ существуют? Как распределить политики по уровням? Что такое бизнес-правила, сущности и варианты использования? Что архитектура может и должна “кричать”? Описание Чистой Архитектуры.
Четвертая часть книги посвящена принципам объединения компонентов в программные системы.
Эта часть более интересна. Она содержит:
Обзор истории компонентов: возможность перемещения в памяти, линкеры
Три принципа связности компонентов
REP: Принцип эквивалентности повторного использования и выпусков
CCP: Принцип согласованного изменения
CRP: Принцип совместного повторного использования
Три принципа соединения компонентов
ADP: Принцип ацикличности зависимостей
SDP: Принцип устойчивых зависимостей
SAP: Принцип устойчивости абстракций
Мне особенно понравилась эта глава из-за представленных метрик, которые можно использовать для измерения (!) хорошего дизайна ПО (точнее говоря того, как вы следуете некоторым принципам дизайна)
Принцип единственной ответственности: модуль должен быть ответственным перед одним и только одним действующим лицом.
Принцип открытости-закрытости: программный артефакт должен быть открыт для расширения, но закрыт для модификации.
Принцип подстановки Барбары Лисков: S является подтипом T, если вместо экземпляра T мы всегда можем использовать экземпляр S
Принцип разделения интерфейсов: используйте интерфейсы для уменьшения зависимости от изменений.
Принцип инверсии зависимостей: избегайте зависимостей от летучих конкретных элементов.
Ничего нового отсюда я не узнал (но я занимаюсь разработкой программного обеспечения уже более 20 лет;). Тем не менее, это все же хорошее обобщение основных принципов проектирования. И о них стоит помнить.
