[Школа сильных программистов] Анализ систем. Тариф Аптечка (Фёдор Борщёв, Антон Давыдов)

​

4-недельный курс о том, как проектировать системы. Новые — чтобы не переделывать, старые — чтобы разобрать на части и ускорить разработку.

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

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

Спойлер: Программа курса:

Урок 1. Kitten: разбиваем систему на элементы, печём первый блин
Цель: Научиться вынимать требования из бизнеса и выбирать элементы системы на основе этих требований. Узнать первые два вида связности — по данным и по вызовам. Познакомиться с системой, которую будем разбирать во время курса.

Какую проблему решаем?

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

Так же в уроке разбиваем два антипаттерна — разбивание бизнес-логики по техническим шагам (нужен пример) или по сущностям (entity service)

Ключевые концепции и термины:

• Работа с требованиями
• Event Storming
• Модель данных
• Базовое сравнение микросервисов и монолитов
• система, форма и функция системы

На выходе:

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

Урок 2. House Cat: Выбираем архитектурный стиль на основе стратегического анализа бизнеса
Цель: Проанализировать полученную в первом уроке систему и найти ее слабые места. Разобраться в явных и не явных видах связанности, связать связанность и сложность системы. Посмотреть на проект глазами бизнеса, что бы избавиться от лишней связанности между элементами. Определиться, какие характеристики важны для системы, найти их значения и выбрать один из базовых архитектурных стилей, основанных на найденных характеристиках

Какую проблему решаем?

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

Ключевые концепции и термины:

• Strategy DDD, Core/Generic/Supporting subdomain, context mapping
• coupling & cohesion, temporal coupling, local & global complexity
• quality attributes/non functional requirements/architecture characteristics
• поиск характеристик и перевод бизнес терминов в характеристики
• циклы жизни систем
• fitness functions
• layered, service-based, microservices architecture styles
• V-model

На выходе:

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

Урок 3. Tomcat: Выбираем коммуникации, брокеры и базы данных, документируем решения
Цель: Определить целевую аудиторию, для которой мы делаем систему, благодаря этому собрать полные требования и полный набор характеристик. Ввести внешние ограничения, благодаря чему система изменится. На основе отличий в характеристиках ввести концепцию разделения на сервисы. Разобраться как выбирать паттерны, базы данных и способы коммуникаций. А так же научиться стандартизировано описывать принятые решения

Какую проблему решаем?

В реализуемой системе заинтересован не только сферический бизнес в виде ПМ-а, но и разные виды пользователей: финотдел, внешние инвесторы, отделы разработки и другие. Для того, что бы полученное решение удовлетворяло всех заинтересованных — необходимо найти эти лица. При этом, важно понять, чей интерес важнее, что бы работа над проектом не превратилась в хаос.

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

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

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

Ключевые концепции и термины:

• stakeholders, stakeholders requirements
• ограничения системы
• microkernel, pipeline, event-driven architecture styles
• Выбор вида БД в зависимости от характеристик
• Выбор вида брокера в зависимости от характеристик
• Выбор паттернов в зависимости от характеристик
• ADR

На выходе:

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

Урок 4. Alley Cat: Распиливаем монолит
Цель: Попасть в ситуацию, когда уже есть готовая реализация проекта, который сделали “как смогли”. После анализа полученной системы, привести все в порядок, используя пять подходов: добавить новый функционал, как отдельный сервис, объединить технические шаги в общий сервис, переписать существующий сервис, что бы он удовлетворял характеристикам, вынести сервис из монолита и избавиться от энтити сервиса. Для каждой проблемы обсудить стратегии вывода в эксплуатацию и шаги для переписывания.

Какую проблему решаем?

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

Ключевые концепции и термины:

• Entity services
• Strangler Fig Application
• Пока не могу написать все паттерны, там их много. Если прямо срочно - могу собрать

На выходе:

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

Урок 5. Итоги и дальнейшие шаги
Цель: Подвести общие итоги и обсудить необходимые шаги для дальнейшей работы. Разобраться, как описывать систему. Спланировать этап развития собственных навыков после курса и повторить концепции пройденные в курсе.

Какую проблему решаем?

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

Ключевые концепции и термины:

• все, что в курсе было
• 4+1, C4, arc42, iso42010

На выходе:

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

Скрытый текст. Доступен только зарегистрированным пользователям.Нажмите, чтобы раскрыть...