Основная проблема с event-driven архитектурой - это снижение прозрачности в runtime. Когда бизнес-логика ОДНОГО связонного бизнес процесса разносится по множеству подписчиков, становится крайне сложно отследить, кто инициирует действие, в каком порядке обрабатываются события, какие компоненты участвуют в цепочке на каком этапе БИЗНЕС процес. Состояние начинает быть размазанным по разным компонентам.
Пример с циркулярными событиями -- симптом этой сложности.
Прблемы с отладкой -- В отличие от прямого вызова, при асинхронной передаче событий стек вызовов теряется не понятно откуда событие прилетает и чем оно было инициировано, как результатполучаются сложные сети событий, что ведет к тому что во первых IDE не может помочь в работе (не может проследить цепочку) и к тому что резко растут требования к документации нужны схемы потоков событий, архитектурные диаграммы и пр. в противном случае разработчики быстро теряют понимание, как работает система в целом.
Проблема с версиями событий... вы так изящно перешли с V1 на V2 но в реальном то мире это не работает, нужно будет что то что будет транслировать V2 в V1 иначе у вас получается 2 параленльных системы. И там начинается :) и я еще не начал про идемпотентность
Очень сильно рекомендую попробовать Snap! https://snap.berkeley.edu/ ничего устанавливать не нужно, работает в браузере. Кроме обычных блоков там добавлена возможность делать свои собственные блоки. И ряд блоков которые превращают его в нормальный функциональный язык. Это прежде всего списки, замыкания, функции высшего порядка и пр. Гораздо веселее ;) Есть макросы!
Пока еще сильно не понятно кто будет вообще отвечать в такой ситуации. Производители автопилотов точно не хотят этой ответственности. Если регулятор не запихает это им силком то скорее всего ее повесят на "водителя" ... просто потому что больше не на кого.
Не плохо работает для весьма узкого класса задач, так как тащит за собой ряд проблем про которые совсем не говорится в статье. Банально сделать какой нибудь отчёт, который традиционно можно сделать одним SQL запросом, становится весьма не тривиальной задачей.
Основная проблема с event-driven архитектурой - это снижение прозрачности в runtime. Когда бизнес-логика ОДНОГО связонного бизнес процесса разносится по множеству подписчиков, становится крайне сложно отследить, кто инициирует действие, в каком порядке обрабатываются события, какие компоненты участвуют в цепочке на каком этапе БИЗНЕС процес. Состояние начинает быть размазанным по разным компонентам.
Пример с циркулярными событиями -- симптом этой сложности.
Прблемы с отладкой -- В отличие от прямого вызова, при асинхронной передаче событий стек вызовов теряется не понятно откуда событие прилетает и чем оно было инициировано, как результатполучаются сложные сети событий, что ведет к тому что во первых IDE не может помочь в работе (не может проследить цепочку) и к тому что резко растут требования к документации нужны схемы потоков событий, архитектурные диаграммы и пр. в противном случае разработчики быстро теряют понимание, как работает система в целом.
Проблема с версиями событий... вы так изящно перешли с V1 на V2 но в реальном то мире это не работает, нужно будет что то что будет транслировать V2 в V1 иначе у вас получается 2 параленльных системы. И там начинается :) и я еще не начал про идемпотентность
Очень сильно рекомендую попробовать Snap!
https://snap.berkeley.edu/
ничего устанавливать не нужно, работает в браузере.
Кроме обычных блоков там добавлена возможность делать свои собственные блоки. И ряд блоков которые превращают его в нормальный функциональный язык. Это прежде всего списки, замыкания, функции высшего порядка и пр. Гораздо веселее ;)
Есть макросы!
была новость не знаю ушло ли в прод это
https://3dnews.ru/1092605/v-yandekse-razrabativayut-ustroystvo-kompensiruyushchee-podavlenniy-signal-gps
у меня с поддержкой яндекс такси не было ни когда проблем. Все вопросы решались в мою пользу + ваучер 250 руб на след поездку.
есть еще простой способ ngrok
без плясок с бубнами, просто, и кондово...
ngrok config add-authtoken <TOKEN>
ngrok http http://localhost:8080
ну по крайней мере мы уверены что наша страна точно туда летала :)
Мне кажется в модели Адизеса нет Аналитика, там есть : P — producer, A — administrator, E — entrepreneur, I — integrator — «интегратор». Галюцинации?
Для того что бы задать 3 вопроса наверное чат гпт не нужен.
и является основной причиной написания Линукса, когда Товальдс не принял от него патчи и разосрался с ним в почте, Линус решил сделать свой лунапарк
Пока еще сильно не понятно кто будет вообще отвечать в такой ситуации. Производители автопилотов точно не хотят этой ответственности. Если регулятор не запихает это им силком то скорее всего ее повесят на "водителя" ... просто потому что больше не на кого.
Не плохо работает для весьма узкого класса задач, так как тащит за собой ряд проблем про которые совсем не говорится в статье. Банально сделать какой нибудь отчёт, который традиционно можно сделать одним SQL запросом, становится весьма не тривиальной задачей.