/bmstu_sd

BMSTU Software design 2022 course

Primary LanguageGo

bmstu_sd

BMSTU Software design 2022 course

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Границы

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

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

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

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

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

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

1-11

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