6911
правок
Изменения
м
[[Файл:TechLeadScribing<big>Серия докладов и мастер-классов про мою визуальную модель для (микро)сервисной архитектуры приложения, которая позволяет проектировать масштабирование и устойчивость приложения и обсуждать решения с бизнесом.jpg|right|400px|thumb|Скрайбинг доклада на TechLead]]</big>
Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулейДоклады на разных конференциях имеют разную фокусировку - работа с требованиями, тестирование, архитектура, и даже на одинаковых слайдах рассказ отличается. Для проектирования использовался процедурный подход Последний доклад по теме '''[[Визуальное проектирование масштабируемых приложений (Вирт "Алгоритмы + Структуры данных = Программы"Highload-2022) или пришедший ему на смену ООП]]'''. В обоих случаях объектная Если вам модель предметной области кажется ценной для развития ее в виде структур справочников и документов и связанная с каждым объектом бизнесмастер-логикаклассы или обучение, созданные аналитиком, служат адекватным проектом для реализации разработчиками в коде, а изменения разработчиками могут быть отражены в модельто я готов сотрудничать. Модель соответствует коду и сложность ее изменения для решения новых требований позволяет примерно оценить сложность разработки ---- [[Файл:TechLeadScribing.jpg|right|400px|thumb|Скрайбинг доклада на TechLead]]
С распространением микросервисной архитектуры Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулей. Для проектирования использовался процедурный подход ('''Вирт «Алгоритмы + Структуры данных = Программы»''') или пришедший ему на смену '''ООП'''. В обоих случаях объектная модель предметной области в виде структур справочников и акторной модели документов и связанная с взаимодействием на асинхронных очередях и событияхкаждым объектом бизнес-логика, объектной модели становится недостаточно. Классические диаграммысозданные аналитиком, UML и другиеслужат адекватным проектом для реализации разработчиками в коде, придуманные а изменения разработчиками могут быть отражены в эпоху монолитов, не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействиеммодель. Требуются иные способы, адекватные применяемым парадигмам программирования, чтобы обеспечить соответствие между моделью Модель соответствует коду и реализацией, проектирование оркестровки и устойчивого работы приложенийсложность ее изменения для решения новых требований позволяет примерно оценить сложность разработки.
Впервые я рассказал о такой С распространением микросервисной архитектуры и акторной модели '''осенью 2020 года [[Модели предметной области для разных парадигм программирования (AnalystDays-2020)]]''', с тех пор доклад развивался взаимодействием на нескольких конференциях с разными фокусами - на проектированиеасинхронных очередях и событиях, тестированиеобъектной модели становится недостаточно. Классические диаграммы, архитектуруUML и другие, масштабированиепридуманные в эпоху монолитов, не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием. Весной 2021 я начал проводить мастер-классыТребуются иные способы, где после краткого рассказа о модели разбирался конкретный кейс от участниковадекватные применяемым парадигмам программирования, чтобы обеспечить соответствие между моделью и реализацией, проектирование оркестровки и устойчивого работы приложений.
По отзывамВпервые я рассказал о такой модели '''осенью 2020 года [[Модели предметной области для разных парадигм программирования (AnalystDays-2020)]]''', с тех пор доклад развивался на нескольких конференциях с разными фокусами — на проектирование, тестирование, модель получилась удачной и позволяет обсуждать архитектуру микросервисного приложения между всеми участниками проекта, включая бизнес-заказчиковмасштабирование. Что необходимоСлайды выступлений близки, так как требования по масштабированию и последствия неустойчивой работы имеют бизнеса фокусы изложения — различны. Весной 2021 я начал проводить мастер-последствия - стоимость устранения, потери из-за аварий против стоимости инфраструктуры с резервированием и надежности, закладываемой в разработку. А такие вопросы необходимо обсуждать с бизнесомклассы, вырабатывая совместные решениягде после краткого рассказа о модели разбирался конкретный кейс от участников.
Последний доклад По отзывам, модель получилась удачной и позволяет обсуждать архитектуру микросервисного приложения между всеми участниками проекта, включая бизнес-заказчиков. Что необходимо, так как требования по теме '''[[Визуальное проектирование масштабируемых приложений (TechLeadмасштабированию и последствия неустойчивой работы имеют бизнес-последствия — стоимость устранения, потери из-2021)]]'''за аварий против стоимости инфраструктуры с резервированием и надежности, закладываемой в разработку. А такие вопросы необходимо обсуждать с бизнесом, вырабатывая совместные решения.
Нет описания правки
[[Категория:Архитектура]]
