Сложное CRUD-приложение — это приложение, в котором бизнес-требования часто выглядят «простыми CRUD-операциями», но сложность разработки и сопровождения определяется не доменными инвариантами, а моделью данных, эффектами (IO) и интеграциями.
Такие системы обычно не требуют экзотических технологий: REST/JSON, реляционная БД, несколько внешних сервисов. И при этом они систематически «перерастают» в код, где трудно предсказать последствия изменений.
Признаки
Большая модель данных: десятки/сотни типов сущностей, много связей, много полей.
«Простые»
Create/Update/Deleteоперации затрагивают десятки таблиц и несколько внешних систем.Нефункциональная сложность доминирует над предметной:
маппинг внешних структур данных на внутренние;
эффективность IO (батчи, параллелизм, кэширование);
обработка частичных отказов и деградация (показать «что есть», но отметить ошибку).
По коду сложно быстро ответить на вопросы:
какие эффекты (БД/HTTP/очереди/почта/файлы) будут выполнены;
сколько IO-вызовов произойдёт;
где границы графа объектов, который создаётся/читается/модифицируется.
Пример: Страница расписания в Trainer Advisor
Операция отображения страницы расписания терапевта звучит как «простой CRUD» сценарий:
взять данные о приёмах из БД;
взять события календарей из нескольких источников;
свести всё в календарную сетку;
если произошёл сбой при загрузке данных — вывести доступные данные и явно обозначить частичную ошибку;
для Google Calendar — выполнять загрузку данных параллельно, чтобы сократить время ожидания пользователя.
Но структурная диаграмма (граф вызовов методов) реализации этой операции не является простой:
Этот кейс показателен тем, что сложность возникает не из-за «глубокой предметной области», а из-за:
маппинга внешних моделей на внутренние;
эффективности IO;
обработки ошибок и частичных отказов.
Разбор реализации и контекст: Trainer Advisor — интеграция с Google Calendar.