Бизнес-процессы приложения (BPMN)
Часть 1: Асинхронный пайплайн импорта, ИИ-распознавания и модерации чеков ОФД
1. Архитектурный регламент моделирования BPMN
При проектировании событийно-ориентированных процессов симулятора FoodLifeCycle ключевой задачей нотации BPMN является визуализация асинхронных межсервисных переходов и точек контроля данных. Процесс импорта продуктов построен по паттерну Fire-and-Forget (Пожар-и-Забыл): тяжелый инференс нейросетей на GPU полностью изолирован от UI мобильного АРМ foodlifecyclemobile1.
Для обеспечения сквозного аудита процессов (Process Mining), каждый шаг диаграммы генерирует стандартизированный маркер в аналитический топик №14 (bpds.pma.out.process.event), где bupar-audit-service агрегирует шаги в цепочки по уникальному case_id.
2. Сквозная BPMN-диаграмма процесса импорта чеков
Диаграмма наглядно разделяет зоны ответственности между Пользователем, Системным шлюзом и Тяжелыми GPU-воркерами (ИИ-слой). Ветвление ромба иллюстрирует петлю обратной связи — ИИ-модерацию при низком уровне уверенности распознавания номенклатур.
3. Регламент шагов и оркестрации данных
- Шаг 1 (U_Snap): Пользователь нажимает кнопку
1. Shop. Камера захватывает фрейм. Сессия метится сквознымtrace_id. - Шаг 2 (G_Upload): Файл отправляется в
MinIO S3. Интерфейс Flutter разблокируется мгновенно благодаря асинхронному статусуHTTP 202 Accepted. Задача пушится в топикbpds.inventory.in.receipt.upload(Топик №1). - Шаг 3-4 (AI_OCR / AI_NER): GPU-контейнеры обрабатывают текст. Если Ollama возвращает строгую JSON-структуру БЖУ с высоким коэффициентом уверенности, шаг модерации пропускается.
- Шаг 5-6 (G_Ticket / U_Review): При нечетком сканировании данные улетают в таблицу
moderation_ticketsСУБДmdm_db. Пользователь получает пуш-нотификацию, корректирует черновик на экране смартфона и закрывает тикет. - Шаг 8 (G_Commit): Происходит двойной атомарный коммит: сумма чека фиксируется в
billing_db, а партии товаров зачисляются поштучно воfridge_db.bupar-audit-serviceперехватывает финал и вносит записьPRODUCT_BATCH_PURCHASEDвbupar_dbпо маркеруcase_id.
4. Архитектурный контекст кулинарного контура (COOK)
Вторая часть спецификации описывает сквозной бизнес-процесс кулинарного цикла платформы FoodLifeCycle, запускаемый по нажатию кнопки 3. Cook. В отличие от асинхронного ИИ-пайплайна закупок, процесс приготовления еды является синхронным и жестко транзакционным.
Ключевой вызов проектирования — оркестрация gRPC-взаимодействия между recipes-service (который хранит тех-карты) и fridge-service (который управляет остатками). Процесс должен атомарно выполнить итерационную проверку и списание партий сырья по правилу FIFO, не создавая взаимных блокировок в fridge_db. Любое отклонение (нехватка объемов в контуре OFFICE) должно мгновенно прерывать цепочку и транслировать каноничный код ошибки на фронтенд.
5. Сквозная BPMN-диаграмма кулинарного процесса
Диаграмма наглядно иллюстрирует цикл перебора партий внутри FIFO-движка холодильника и разветвление логики в зависимости от типа мультитендентного пространства (HOME / OFFICE) при обнаружении виртуальных недостач.
6. Регламент шагов кулинарной оркестрации
- Выбор и Валидация (Шаги 1-2): Пользователь тапает на карточку блюда.
backend-apiпрокидывает команду вrecipes-service. Происходит чтение состава тех-карты. Если рецепт удален, система мгновенно выбрасываетMDM_RECIPE_NOT_FOUND(HTTP 404). - FIFO-Сортировка (Шаг 3):
fridge-serviceоткрывает транзакцию вfridge_dbи выстраивает партии нужных ингредиентов по дате создания (created_at ASC), чтобы первыми расходовать продукты, у которых первыми истекает срок годности. - Итеративный вычет (Шаг 4): Объем уменьшается. Если текущая партия исчерпана, её
quantityстановится равным0, и алгоритм переходит к следующей записи. - Обработка дефицита (Шлюзы):
- Если общего объема всех партий не хватило, а сессия принадлежит группе
OFFICE, транзакция полностью откатывается (ROLLBACK), предотвращая кражу чужой еды на общей кухне. На фронтенд возвращается gRPC-кодFAILED_PRECONDITION. - Если сессия принадлежит группе
HOME,fridge-serviceразрешает загнать баланс конкретной партии в минус (виртуальная недостача), чтобы не ломать сценарий симуляции, если семья просто забыла сфотографировать новый чек.
- Если общего объема всех партий не хватило, а сессия принадлежит группе
- Выпуск готового блюда (Шаг 5): В базу записывается новая сущность (например, «Суп Борщ») объемом в порциях и флагом
is_cooked = TRUE.bupar-audit-serviceасинхронно забирает событие из топика №14 (bpds.pma.out.process.event) и склеивает пройденные яблоками и мясом шаги в общую цепочку Process Mining поcase_id.
7. Архитектурный контекст прямого выбытия и фоновых регламентов
Третья часть спецификации регламентирует операционные процессы выбытия продуктов без кулинарной обработки. Сюда входят прямое ручное съедение продуктов (CONSUME), утилизация испорченной еды (WASTE) с использованием речевого ИИ-инференса (Whisper tiny), а также автономный фоновый процесс автоматического списания просроченных товаров.
Ключевой вызов проектирования — оркестрация асинхронного голосового ввода с контролем текстовой безопасности [bupar-audit-service]. Потоковая аудиозапись рапорта пользователя проходит сквозную цензуру. В случае обнаружения обсценной лексики система должна атомарно инкрементировать счетчик нарушений в Redis и принудительно терминировать сессию при превышении лимита (2 попытки), защищая ИИ-симуляцию от загрязнения.
8. Сквозная BPMN-диаграмма выбытия и фонового списания
Диаграмма декомпозирует шаги пользователя при голосовом списании отходов, логику ветвления ИИ-цензора, а также изолированный автономный процесс ночного планировщика Celery Beat.
9. Регламент шагов и автоматизации выбытия
- Голосовой рапорт и Whisper-инференс (Шаги 1-2): Находясь на кухне, пользователь удерживает кнопку
5. Wasteи диктует: «Выбросил 400 грамм протухшего молока». Аудиочанги аккумулируются вMinIO S3. Сервисgrpc-analytics Речь Голосвычитывает топик №1, скачивает аудиофайл и транскрибирует его в сырой текст с помощью модели Whisper tiny. - ИИ-Цензура и Блокировка (Шаг 3 и Шлюзы): Текст пушится в топик
bpds.inventory.in.receipt.uploadи перехватываетсяcensorship-control-worker.- Если обсценная лексика не обнаружена, строка парсится Ollama, и
waste-serviceчерезfridge-serviceпроводит каскадный FIFO-вычет испорченного объема еды. - Если зафиксирован мат, срабатывает атомарный Redis Lua-скрипт инкремента. При достижении
violation_count >= 2воркер публикует критическое событие в топик №13 (bpds.aid.out.profanity.violate). Сессия авторизации пользователя аннулируется вauth-service, токен заносится в Blacklist, а приложение переходит на жесткий экран блокировкиSECURITY_PROFANITY_BAN(HTTP 403).
- Если обсценная лексика не обнаружена, строка парсится Ollama, и
- Автономная ночная утилизация просрочки (Celery Beat): В 03:00 ночи, когда симуляторы неактивны, планировщик Celery Beat запускает метод
reconcileбазы данныхFridge_db. Робот сканирует партии товаров, выявляет позиции с условиемexpired_at < NOW(), принудительно обнуляет ихquantityи переводит в статусEXPIRED. - След в Process Mining: Как при ручной утилизации отходов (
FOOD_WASTED), так и при автоматическом ночном списании просрочки роботом (SHORTAGE_RECONCILED), система отправляет JSONB-слепки параметров в топик №14 (bpds.pma.out.process.event).bupar-audit-serviceфиксирует эти данные, завершая жизненный цикл конкретного продукта на глобальном аналитическом дашборде.