Является ли сохранение контекста бизнес-процесса в базе данных архитектурной ошибкой?

Нет, это не ошибка, а распространённый и валидный паттерн для управления состоянием долгоживущих процессов (например, Saga или State Machine). Ключ — в корректной реализации.

Рекомендации:

1. Храните только ключевые данные: ID, статус, параметры процесса. Избегайте сериализации больших объектов графа доменных сущностей.
2. Используйте оптимистичную блокировку (@Version) для предотвращения race condition при параллельном обновлении состояния.
3. Оптимизируйте структуру хранения: используйте тип JSONB в PostgreSQL или TEXT с валидацией в других СУБД.

Пример реализации на Java (Spring Data JPA):

@Entity
public class ProcessInstance {
    @Id
    private String id;
    private String status;

    @Column(columnDefinition = "TEXT")
    private String contextData; // JSON с контекстом (например, orderId, paymentToken)

    @Version
    private Long version; // Для оптимистичной блокировки
}

Альтернативы: Для сложных workflow рассмотрите специализированные движки (Camunda, Flowable) или Event Sourcing (с хранением событий в Kafka/Cassandra). Однако для многих случаев хранение контекста в БД — это простое и надёжное решение.