#business_process — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #business_process, aggregated by home.social.
-
[Перевод] Дисциплина процессов — это скучно. Поэтому она и нужна агентам
После нескольких успешных пилотных проектов с агентами многие организации начинают тихо обнаруживать, что прирост эффективности куда-то утекает. Разрозненные агенты создают повторную работу, конфликты и пограничные случаи, за которые никто не отвечает. Разговаривая с заказчиками, я понял, что уже видел этот фильм. У каждой технологической волны есть вопрос, который задним числом кажется очевидным, но в разгар всеобщего энтузиазма его пропускают. Для микросервисов это был вопрос: кто на самом деле отвечает за сквозной поток клиентского сценария? Для агентов, думаю, вопрос тот же. Обещание микросервисов заключалось в том, что команды разработки смогут оставаться независимыми и двигаться быстрее — сервисы просто будут реагировать на события, без необходимости координации. Вначале это даже работало. Добавить новый сервис было легко: достаточно было начать потреблять события из уже существующей системы, не нужно было разговаривать ни с одним производителем событий. Команды двигались быстро. Доминирующий стиль координации назывался хореографией: сервисы не общаются друг с другом напрямую. Вместо этого они генерируют события (например, заказ размещён, платёж подтверждён, товар зарезервирован), а другие сервисы независимо реагируют на эти события. Таким образом, не нужен центральный координатор и, возможно, даже не нужно задавать явную последовательность. Каждый сервис занимается своим делом, в результате чего получается слабо связанная архитектура (спойлер: слабо связанной она не была — как я разобрал в докладе под названием «Слабая или паршивая связанность? Понимаем паттерны коммуникации в микросервисных архитектурах» ).
-
Camunda на проде: восемь типичных ошибок
Итак, вы смоделировали все процессы, написали бизнес-логику и задеплоили все на сервер. Запускаем наши процессы на проде! Поехали? – Но дальше разложено множество граблей, на которые обычно наступают все, кто только начинает эксплуатировать BPM, в том числе и на движке Camunda 7 . Эта статья сэкономит вам много времени и успокоит нервы – потому что ситуации, описанные ниже, могут изрядно их попортить, если вы будете не готовы.
-
[Перевод] Переход от встроенных к удалённым BPM-движкам
В течение длительного времени мы выступали за архитектуру, в которой BPM-движок Camunda встроен в ваше Java-приложение, предпочтительно через Camunda Spring Boot Starter. Однако со временем мы постепенно отошли от этой рекомендации в сторону удалённого движка. В Zeebe мы и вовсе не поддерживаем использование встроенного движка. В этом посте я хочу объяснить причины этого перехода и почему мы рекомендуем использовать удалённый движок. Однако сначала давайте разберёмся, почему встроенный движок изначально представлял собой привлекательный выбор, и отметим, что изменилось с течением времени. Если вам не интересна эволюция данного вопроса, вы можете пропустить историческую справку и перейти к сравнению архитектур движков.
-
Business Process Notation как подход к организации кода в проекте по разработке мобильного iOS приложения
Постановка проблемы На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code. Все они в той или иной мере работают с тремя основными сущностями - Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter. Вторая общая особенность данных архитектурных паттернов состоит в том, что названные выше сущности выделяются и классифицируются исходя из их технических характеристик. Например, Вью - это то, что отображает данные на экране, Модель - содержит в себе данные и их обработку, а Контроллер осуществляет взаимодействие между ними. Но эти характеристики не отражают сущности приложения в целом. Это как если бы мы разделили воду на водород и кислород и пытались бы из их особенностей понять сущность воды. Фрагментарность используемых сущностей и отсутствие целостного видения приложения приводит к общеизвестным проблемам, связанным с трудностями понимания кода и его управлением. Отсюда, ни один из этих паттернов не гарантирует, что на определённом этапе разработки приложения не возникнет ситуация, когда код станет тяжеловесным и очень сложным для управления. Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д. Продолжая пример с изучением воды следует сказать, что единицей её анализа является молекула воды. Это мельчайшая частица воды, которая тем не менее содержит в себе все её свойства. В программе такой мельчайшей и одновременно целостной единицей является задача, которую решает тот или иной блок кода. Отсюда, возникла идея использовать в качестве отправного пункта для организации кода именно те задачи, которые этот код решает. При этом, задача понимается как бизнес-процесс.
https://habr.com/ru/articles/866376/
#ios_development #business_process #architecture_pattern #организация_кода #навигация_проекта #MVC #MVVM #VIPER #модель_приложения #swift