Comments 5
не хватает еще примера с альтернативными вариантами действий в последовательности.
Сори за духоту, но синхронный ответ другой стрелкой рисуется. Там должна быть не закрашенная))
-->>
Спасибо за статью! На мой взгляд, статья содержит несколько антипаттеронов и плохих дизайнов. Вот пару из них:
Сохранение бизнес-данных в хранилище Processing Service.
Если сервис лишь обрабатывает данные, а не владеет ими, сохранять их у себя нет смысла. Это приводит к дублированию и неконсистентности. Например, если данные в Service A уже были обновлены другим процессом или user-ом, Processing Service может оперировать устаревшей информацией, что вводит в заблуждение и нарушает целостность бизнес-логики.loop зависимых объектов через Service A
Такой подход создаёт лишнюю нагрузку на сервис, особенно при большом количестве зависимостей. Вместо этого эффективнее получить все связанные данные одним запросом к базе (например, с join или batch-загрузкой) и вернуть агрегированный результат. Это не только быстрее, но и транзакционно безопаснее.
Спасибо за замечания. Я согласна, что есть кейсы, когда указанные вами моменты действительно стоит учесть и скорректировать процесс. Я строила диаграмму на основе той системы, с которой работаю, и в нашем случае данных проблем нет. Перелив данных в целевую систему не редкость и имеет свои плюсы. Мне было важно описать построение диаграммы. Действительно нужно отметить, что сам процесс не стоит брать за основу, так как это всё зависит от имеющейся архитектуры, целей и задач.
Диаграмма последовательности на практике в реальном кейсе