bmstu_sd

BMSTU Software design 2022 course

Лекция №4. 28.03.2022. Тема: архитектура.

Уровни решения задачи:

Уровни бизнеса:

Что решаем;
Для чего решаем (контекст решения);
Для кого решаем;
В каких условиях решаем.

Уровень архитектуры:

Как решаем? - вытекает из уровней бизнеса.

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

Какие задачи решает архитектура?

Поддержание жизненного цикла ПО;
Легкость освоения;
Простота разработки, совпровождения и развертывания;
Минимизация затрат на проект;
Максимизация продуктивности программистов.

Как писать unit-тесты, если методы выполняют несколько задач? Метод должен выполнять одну конкретную задачу. Если вы думаете, что хорошая архитектура - это дорого, попробуйте плохую. Архитектура рождается на балансе требований. Идеальное сопровождение - когда ПО максимально гибкое.

Зависимость разных аспектов проекта от архитектуры:

Сверхсильная зависимость:

Сопровождение (исправление ошибок, модификация, тех. поддержка)

Сильная завимость

Разработка, развертывание

Слабая/неоднозначная зависимость

Эффективность

Почти нулевая зависимость

Функциональность

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

Хороший архитектор максимизирует количество непринятых решений.

Баланс. Неизвестные и переменные факторы

Все варианты использования;
Эксплутационные ограничения;
Структура команды разработчиков;
Требования к развертыванию;
Специфика применения(команда не учла, как именно люди будут использовать функционал);
Внешняя ситуация.

Организация архитектуры. Горизонтальные уровни

Режем по причинам изменений. Уровень -удаленность от ввода и вывода.

1 уровень - бизнес-правила, связанные с предметной областью. (Самый близкий политикам. То, что скорее всего не будет меняться ни при каких условиях);
2 уровень - бизнес-правила, связанные с приложением. (Ближе к деталям. Как мы предметную область переложили на пользовательский сценарий);
3 уровень - UI, БД, драйверы внешних устройств. (Все те детали, засчет которых реализуется приложение).

Эти слои не являются монолитными, состоят из компонентов. Компоненты выделяются с помощью вертикальных срезов (реализация конкретного пользовательского сценария). Компоненты связаны прежде всего отношением зависимости.

Вертикальные узкие срезы

Режем по меняющимся и повторяющимся вариантам использования(Use Case).

Срез варианта использования:

Часть UI;
Часть бизнес-логики приложения;
Часть бизнес-логики предметной области;
Чвсть БД.

Тонкости дублирования

Устранение истинного дублирования;
Похожие сущности и алгоритмы в разных уровнях и срезах - это нормально.

Реальное или ложное дублирование? Реальное - объединять в обобщающий компонент. Не весь похожий код следует объединять в модули.

Режимы разделения компонентов

Уровень исходного кода(монолит);
Уровень развертывания;
Уровень локального независимового выполнения (отдельные компоненты - не просто динамические библиотеки, а реально исполняемые файлы, при запуске образующие процессы, локлаьно умеют работать на одной машине, меняется способ их связи между собой, shared memory/файл/БД);
Уровень служб (сервис, микросервис. Некоторый процесс, который исполянется по-настоящему независимо. Способ связи между компонентами - сетевые протоколы).

Границы

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

Архитектура плагинов:

Независимые высокоуровневые компоненты;
Граница;
Зависимые неизкоуровневые компоненты.

Жесткость границ - выопрос выбора архитектора на тему анализа рисков.

Как построить чистую архитектуру?

Независимость от фреймворков;
Простота тетсирования;
Независимость от UI;
Независимость от БД;
Незавиисимость от любых внешних агентов;
Явная зависимость от назначения.

Эта "луковица" - критерий чистоты архитектуры. Main - на верхнем слое.

deuuus/bmstu_sd