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

4-недельный курс о том, как проектировать системы. Новые — чтобы не переделывать, старые — чтобы разобрать на части и ускорить разработку.Научим распиливать монолиты, обоснованно выбирая технологии и архитектурные стили, оставляя после себя понятную документацию.Вы спроектируете архитектуру проекта на основе собранных требований. Сделаете модель данных, опишете коммуникации, определите субдомены и архитектурные характеристики проекта. Всё это будет эволюционировать параллельно с новыми знаниями с курса.Программа курса:Урок 1. Kitten: разбиваем систему на элементы, печём первый блинЦель: Научиться вынимать требования из бизнеса и выбирать элементы системы на основе этих требований. Узнать первые два вида связности — по данным и по вызовам. Познакомиться с системой, которую будем разбирать во время курса.Какую проблему решаем?Когда мы только начинаем проектировать системы, обычно нет ни внятных требований, ни времени на проектирование. После урока будет понятно, что даже в таких условиях можно собрать что-то рабочее.Так же в уроке разбиваем два антипаттерна — разбивание бизнес-логики по техническим шагам (нужен пример) или по сущностям (entity service)Ключевые концепции и термины:Работа с требованиямиEvent StormingМодель данныхБазовое сравнение микросервисов и монолитовсистема, форма и функция системыНа выходе:Спроектируем первую версию системы. Для этого рассмотрим две базовые модели: Event Storming и Модель данных. Благодаря этим моделям, в будущем, будем улучшать систему с каждой новой итерацией.Урок 2. House Cat: Выбираем архитектурный стиль на основе стратегического анализа бизнесаЦель: Проанализировать полученную в первом уроке систему и найти ее слабые места. Разобраться в явных и не явных видах связанности, связать связанность и сложность системы. Посмотреть на проект глазами бизнеса, что бы избавиться от лишней связанности между элементами. Определиться, какие характеристики важны для системы, найти их значения и выбрать один из базовых архитектурных стилей, основанных на найденных характеристикахКакую проблему решаем?После первой итерации, оказалось, что не были учтены не явные связи между найденными элементами, а сами элементы были найдены без понимания какую проблему изначально решает бизнес. При этом, выбранная структура из первого урока оказалась не валидной ибо мы не учли важные характеристики проекта. Поэтому, научимся искать характеристики и выбирать архитектурные стили основываясь на полученных данныхКлючевые концепции и термины:Strategy DDD, Core/Generic/Supporting subdomain, context mappingcoupling & cohesion, temporal coupling, local & global complexityquality attributes/non functional requirements/architecture characteristicsпоиск характеристик и перевод бизнес терминов в характеристикициклы жизни системfitness functionslayered, service-based, microservices architecture stylesV-modelНа выходе:Ученик научится смотреть на систему как на набор проблем, решения которых ему надо спроектировать. Научится видеть связанность элементов не только явную, но и основанную на бизнесе и характеристиках. Разберется в том, какие характеристики существуют, как их найти и как с помощью характеристик выбрать нужный архитектурный стиль. Разберем, почему описывать детальное решение для разработчиков не имеет никакого смысла и вместо этого, лучше описать элементы, коммуникации и задать ограничения, в которых должна работать системаУрок 3. Tomcat: Выбираем коммуникации, брокеры и базы данных, документируем решенияЦель: Определить целевую аудиторию, для которой мы делаем систему, благодаря этому собрать полные требования и полный набор характеристик. Ввести внешние ограничения, благодаря чему система изменится. На основе отличий в характеристиках ввести концепцию разделения на сервисы. Разобраться как выбирать паттерны, базы данных и способы коммуникаций. А так же научиться стандартизировано описывать принятые решенияКакую проблему решаем?В реализуемой системе заинтересован не только сферический бизнес в виде ПМ-а, но и разные виды пользователей: финотдел, внешние инвесторы, отделы разработки и другие. Для того, что бы полученное решение удовлетворяло всех заинтересованных — необходимо найти эти лица. При этом, важно понять, чей интерес важнее, что бы работа над проектом не превратилась в хаос.Кроме характеристик, существуют внешние ограничения, такие как законы, количество инвестиций, общий уровень инженеров и так далее. Важно подстраивать решение под эти ограничения, для этого научимся искать и приоритизировать ограничения.Кроме выбора архитектурных стилей, набор ограничений и характеристик можно применять к выбору других технических решений, например баз данных, способах коммуникации, выбору брокера и паттернов.Научимся не только принимать решения, но и описывать их так, чтобы не терять контекст, в котором решение было принято. Это позволит быстрее онбордить новых участников команды.Ключевые концепции и термины:stakeholders, stakeholders requirementsограничения системыmicrokernel, pipeline, event-driven architecture stylesВыбор вида БД в зависимости от характеристикВыбор вида брокера в зависимости от характеристикВыбор паттернов в зависимости от характеристикADRНа выходе:Ученик научится искать заинтересованные в системе лица, определять что из требований заинтересованных лиц важно, а что нет. Научится искать ограничения, которые влияют на итоговое решение и выбирать нужные стили, паттерны, базы данных и любые другие технические решения, основываясь на полученных знаниях. Научится описывать процесс принятия решения так, что бы контекст не терялся.Урок 4. Alley Cat: Распиливаем монолитЦель: Попасть в ситуацию, когда уже есть готовая реализация проекта, который сделали “как смогли”. После анализа полученной системы, привести все в порядок, используя пять подходов: добавить новый функционал, как отдельный сервис, объединить технические шаги в общий сервис, переписать существующий сервис, что бы он удовлетворял характеристикам, вынести сервис из монолита и избавиться от энтити сервиса. Для каждой проблемы обсудить стратегии вывода в эксплуатацию и шаги для переписывания.Какую проблему решаем?Научиться рефакторить распределенные системы: добавлять новый функционал, выносить не подходящий по характеристикам, объединять сервисы, переписывать существующие сервисы и избавляться от энтити сервисов. Так же, обсудим, как планировать и следить за процессом эволюции сисиемыКлючевые концепции и термины:Entity servicesStrangler Fig ApplicationПока не могу написать все паттерны, там их много. Если прямо срочно - могу собратьНа выходе:Ученик получит практический опыт модернизации сервисных архитектур. Получит один из способов наблюдения за процессом работы над системой, который можно применять не только для распила сервисов, но и в любой другой работе над системой.Урок 5. Итоги и дальнейшие шагиЦель: Подвести общие итоги и обсудить необходимые шаги для дальнейшей работы. Разобраться, как описывать систему. Спланировать этап развития собственных навыков после курса и повторить концепции пройденные в курсе.Какую проблему решаем?Собрать все знания вместе. Научиться описывать архитектуру системы так, что бы ей можно было пользоваться.Ключевые концепции и термины:все, что в курсе было4+1, C4, arc42, iso42010На выходе:Ученик получит чеклист работы над системой, дальнейшие шаги по самостоятельному изучению и описание примеров того, как можно описывать архитектуру.