Категория:Акторная модель — различия между версиями
м |
м |
||
| Строка 1: | Строка 1: | ||
[[Файл:TechLeadScribing.jpg|right|400px|thumb|Скрайбинг доклада на TechLead]] | [[Файл:TechLeadScribing.jpg|right|400px|thumb|Скрайбинг доклада на TechLead]] | ||
| − | Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулей. Для проектирования использовался процедурный подход (Вирт | + | Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулей. Для проектирования использовался процедурный подход ('''Вирт «Алгоритмы + Структуры данных = Программы»''') или пришедший ему на смену '''ООП'''. В обоих случаях объектная модель предметной области в виде структур справочников и документов и связанная с каждым объектом бизнес-логика, созданные аналитиком, служат адекватным проектом для реализации разработчиками в коде, а изменения разработчиками могут быть отражены в модель. Модель соответствует коду и сложность ее изменения для решения новых требований позволяет примерно оценить сложность разработки. |
| − | С распространением микросервисной архитектуры и акторной модели с взаимодействием на асинхронных очередях и событиях, объектной модели становится недостаточно. Классические диаграммы, UML и другие, придуманные в эпоху монолитов, не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием. Требуются иные способы, адекватные применяемым парадигмам программирования, чтобы обеспечить соответствие между моделью и реализацией, проектирование оркестровки и устойчивого работы приложений. | + | С распространением микросервисной архитектуры и акторной модели с взаимодействием на асинхронных очередях и событиях, объектной модели становится недостаточно. Классические диаграммы, UML и другие, придуманные в эпоху монолитов, не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием. Требуются иные способы, адекватные применяемым парадигмам программирования, чтобы обеспечить соответствие между моделью и реализацией, проектирование оркестровки и устойчивого работы приложений. |
| − | Впервые я рассказал о такой модели '''осенью 2020 года [[Модели предметной области для разных парадигм программирования (AnalystDays-2020)]]''', с тех пор доклад развивался на нескольких конференциях с разными | + | Впервые я рассказал о такой модели '''осенью 2020 года [[Модели предметной области для разных парадигм программирования (AnalystDays-2020)]]''', с тех пор доклад развивался на нескольких конференциях с разными фокусами — на проектирование, тестирование, архитектуру, масштабирование. Весной 2021 я начал проводить мастер-классы, где после краткого рассказа о модели разбирался конкретный кейс от участников. |
| − | По отзывам, модель получилась удачной и позволяет обсуждать архитектуру микросервисного приложения между всеми участниками проекта, включая бизнес-заказчиков. Что необходимо, так как требования по масштабированию и последствия неустойчивой работы имеют бизнес- | + | По отзывам, модель получилась удачной и позволяет обсуждать архитектуру микросервисного приложения между всеми участниками проекта, включая бизнес-заказчиков. Что необходимо, так как требования по масштабированию и последствия неустойчивой работы имеют бизнес-последствия — стоимость устранения, потери из-за аварий против стоимости инфраструктуры с резервированием и надежности, закладываемой в разработку. А такие вопросы необходимо обсуждать с бизнесом, вырабатывая совместные решения. |
Последний доклад по теме '''[[Визуальное проектирование масштабируемых приложений (TechLead-2021)]]''' | Последний доклад по теме '''[[Визуальное проектирование масштабируемых приложений (TechLead-2021)]]''' | ||
[[Категория:Архитектура]] | [[Категория:Архитектура]] | ||
Версия 12:04, 9 июля 2021
Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулей. Для проектирования использовался процедурный подход (Вирт «Алгоритмы + Структуры данных = Программы») или пришедший ему на смену ООП. В обоих случаях объектная модель предметной области в виде структур справочников и документов и связанная с каждым объектом бизнес-логика, созданные аналитиком, служат адекватным проектом для реализации разработчиками в коде, а изменения разработчиками могут быть отражены в модель. Модель соответствует коду и сложность ее изменения для решения новых требований позволяет примерно оценить сложность разработки.
С распространением микросервисной архитектуры и акторной модели с взаимодействием на асинхронных очередях и событиях, объектной модели становится недостаточно. Классические диаграммы, UML и другие, придуманные в эпоху монолитов, не слишком хорошо позволяют обсуждать архитектуру работы множества сервисов с асинхронным взаимодействием. Требуются иные способы, адекватные применяемым парадигмам программирования, чтобы обеспечить соответствие между моделью и реализацией, проектирование оркестровки и устойчивого работы приложений.
Впервые я рассказал о такой модели осенью 2020 года Модели предметной области для разных парадигм программирования (AnalystDays-2020), с тех пор доклад развивался на нескольких конференциях с разными фокусами — на проектирование, тестирование, архитектуру, масштабирование. Весной 2021 я начал проводить мастер-классы, где после краткого рассказа о модели разбирался конкретный кейс от участников.
По отзывам, модель получилась удачной и позволяет обсуждать архитектуру микросервисного приложения между всеми участниками проекта, включая бизнес-заказчиков. Что необходимо, так как требования по масштабированию и последствия неустойчивой работы имеют бизнес-последствия — стоимость устранения, потери из-за аварий против стоимости инфраструктуры с резервированием и надежности, закладываемой в разработку. А такие вопросы необходимо обсуждать с бизнесом, вырабатывая совместные решения.
Последний доклад по теме Визуальное проектирование масштабируемых приложений (TechLead-2021)
Страницы в категории «Акторная модель»
Показано 9 страниц из 9, находящихся в данной категории.
- Блог:Максима Цепкова/2023-02-01: Микросервисные гномики и парадигмы разработки - аналитические чаепития
- Визуальное проектирование масштабируемых приложений (Highload-2022)
- Визуальное проектирование масштабируемых приложений (TechLead-2021)
- Модели предметной области для разных парадигм программирования (AnalystDays-2020)
- Модели приложения для разных парадигм программирования (ArchDays-2020)
- Модели приложения для разных парадигм программирования (SQAdays-2020)
- Проектируем микросервисное приложение на схемах (мастер-класс ЛАФ-2021)
- Проектируем приложение в микросервисной архитектуре. Разбор кейсов (AnalystDays-2021 весна)
- Тестируем устойчивость приложения в сервисной архитектуре. Разбор кейсов (SQAdays-2021 весна)
