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