Категория:Акторная модель — различия между версиями

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

Текущая версия на 00:34, 8 сентября 2022

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

Доклады на разных конференциях имеют разную фокусировку - работа с требованиями, тестирование, архитектура, и даже на одинаковых слайдах рассказ отличается. Последний доклад по теме Визуальное проектирование масштабируемых приложений (Highload-2022).

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


Скрайбинг доклада на TechLead

Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулей. Для проектирования использовался процедурный подход (Вирт «Алгоритмы + Структуры данных = Программы») или пришедший ему на смену ООП. В обоих случаях объектная модель предметной области в виде структур справочников и документов и связанная с каждым объектом бизнес-логика, созданные аналитиком, служат адекватным проектом для реализации разработчиками в коде, а изменения разработчиками могут быть отражены в модель. Модель соответствует коду и сложность ее изменения для решения новых требований позволяет примерно оценить сложность разработки.

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

Впервые я рассказал о такой модели осенью 2020 года Модели предметной области для разных парадигм программирования (AnalystDays-2020), с тех пор доклад развивался на нескольких конференциях с разными фокусами — на проектирование, тестирование, архитектуру, масштабирование. Слайды выступлений близки, а фокусы изложения — различны. Весной 2021 я начал проводить мастер-классы, где после краткого рассказа о модели разбирался конкретный кейс от участников.

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