Введение: Две философии разработки
В мире корпоративной разработки существует фундаментальное противоречие между стремлением к «чистой» архитектуре (clean code, идеальные паттерны, микросервисы) и необходимостью создавать системы, устойчивые к хаосу реального бизнеса. Это противоречие особенно остро проявляется на пересечении финтеха/инвестиционного бэк-офиса и классической ИТ-продуктовой разработки.
В этой статье мы детально разберём, как эти подходы работают на практике, проиллюстрируем их схемами и графиками и сформулируем сводные рабочие принципы для архитекторов и тимлидов.
Раздел 1: Философский конфликт — «Собор» против «Базара»
```mermaid
graph LR
A[Запрос бизнеса] --> B{Фильтр принятия решения};
B --> C[ИТ-Продукт: Скорость и гибкость];
B --> D[Финтех-Система: Риск и контроль];
C --> C1[Критерий: Time-to-Market];
C --> C2[Метод: Быстрые итерации, MVP];
C --> C3[Допущение: Ошибку можно быстро исправить];
D --> D1[Критерий: Zero-Defect];
D --> D2[Метод: Детальное проектирование, контрольные точки];
D --> D3[Допущение: Ошибка = финансовые/репутационные потери];
```
ИТ-Продукт (Стартап, B2C-сервис):
· Цель: Захват рынка, рост пользовательской базы.
· Ключевая метрика: Time-to-Market (скорость выхода на рынок).
· Допущения: Ошибки в продукте можно быстро исправить «поверх» старой версии. Потеря части данных пользователей — болезненно, но не смертельно для бизнеса. Регуляторное давление минимально.
· Архитектурный идеал: Гибкость, масштабируемость, возможность быстрого рефакторинга.
Корпоративный Финтех (Бэк-офис, риск-менеджмент, учёт):
· Цель: Безошибочность, соответствие регуляторам, аудиту.
· Ключевая метрика: Zero-Defect в критических операциях.
· Допущения: Ошибка в расчёте = прямые финансовые потери, штрафы регулятора, потеря лицензии, судебные иски. Данные — это актив, их целостность и неизменность священны.
· Архитектурный идеал: Предсказуемость, прослеживаемость (audit trail), контроль, неизменность ядра.
Раздел 2: Примеры из практики
Пример А: Обработка изменений в регуляторной отчётности (ЦБ РФ, ФНС)
Ситуация: Изменяется форма ключевой отчётности (например, форма 0409135 «Расчёт величины рыночного риска»). Изменения носят «ломовой» характер: добавляются новые графы, требующие расчёта по историческим данным за 5 лет.
· «Продуктовый» подход (рискованный): Переписать модель данных «красиво», под новую логику. Рассчитать историю заново, перезаписав старые «некрасивые» данные. Выпустить обновление.
· Опасность: Невозможность сформировать отчёт в старой форме для прошлых периодов при проверке. Риск расхождения даже на копейку с ранее поданными данными → немедленные вопросы регулятора.
· «Финтеховый» подход (устойчивый):
1. Версионирование логики: В код расчёта вводится параметр ВерсияФормы = "2024". Вся старая логика остаётся за ВерсияФормы = "2020".
2. Расширение, а не перезапись: Исторические данные остаются в исходном виде. Для новой формы создаются дополнительные поля и таблицы.
3. Двойной прогон: Запускается параллельный расчёт новой формы за последний квартал для сверки.
4. Схематично:
```mermaid
graph TD
subgraph “Старая модель (2020)”
A1[Данные позиций] --> B1[Модуль расчёта v2020] --> C1[Отчёт форма-2020];
end
subgraph “Новая модель (2024)”
A2[Данные позиций] --> B2[Модуль расчёта v2024];
A2 --> D[Новый справочник параметров];
B2 & D --> C2[Отчёт форма-2024];
end
C1 --> E[Архив отчётов: Полная воспроизводимость];
C2 --> E;
```
Вывод: Чистота модели принесена в жертву аудиту и воспроизводимости.
Пример Б: Интеграция с «кривым» API брокера
Ситуация: Автоматическая загрузка биржевых сделок. API брокера может возвращать дубли, терять пакеты, менять формат поля comment без предупреждения.
· «Продуктовый» подход: Использовать современный фреймворк, строгую схему данных (JSON Schema). При любой ошибке или несоответствии — падать с исключением и логировать.
· Результат: Каждый сбой брокера останавливает весь процесс учёта в компании. Операторы в панике.
· «Финтеховый» подход: Реализация устойчивого конвейера с «грязным» карманом.
1. Сырой слой (Raw): Все данные «как есть» пишутся в лог-таблицу с меткой времени.
2. Слой обработки (Staging): Робот пытается распарсить, сопоставить с инструментами. Нераспознанное идёт в таблицу исключений.
3. Слой согласования (Reconciliation): Ежедневно автоматически формируется отчёт о нестыковках (например, расхождение итоговой суммы с выгрузкой брокера в PDF).
4. Слой ручного вмешательства: Оператор просматривает таблицу исключений, вручную «растаскивает» сделки. Его действия логируются для аудита.
```
┌─────────────────┐
│ API Брокера │
│ (Нестабильный) │
└────────┬────────┘
▼
┌─────────────────────────────────────┐
│ СЫРОЙ СЛОЙ (Raw Zone) │
│ ┌─────────────────────────────┐ │
│ │ Таблица RAW_TRADES: │ │
│ │ - id, received_at, │ │
│ │ - raw_json (TEXT) │ │ ◄── «Грязные» данные приняты как факт
│ └─────────────────────────────┘ │
└──────────────────┬──────────────────┘
▼
┌─────────────────────────────────────────────────────┐
│ СЛОЙ ОБРАБОТКИ (Staging) │
│ ┌─────────────────────────────┐ ┌─────────────┐ │
│ │ Таблица STG_TRADES: │ │ ИСКЛЮЧЕНИЯ │ │
│ │ - clean fields... │ │ (Exceptions│ │
│ │ - status ='processed' │ │ Table) │ │
│ └─────────────────────────────┘ └─────────────┘ │
└──────────────────┬──────────────────────────────────┘
▼
┌────────────────────────┐
│ АВТОМАТИЧЕСКАЯ │
│ СВЕРКА (Reconciliation)│
│ Отчёт о расхождениях │
└────────────────────────┘
│
▼
┌────────────────────┐
│ РУЧНОЕ ВМЕШАТЕЛЬСТВО│◄── Контрольная точка
│ (Audit Logged) │ для оператора
└────────────────────┘
```
Раздел 3: Графики и обоснования. Динамика технического долга
График 1: Накопление «архитектурного компромисса» (Технического долга) в разных доменах
```
Уровень сложности/долга
^
| ** Финтех-система **
| . . . . . . . . . . . . . . . . .
| .
| . ◄── Плановые "компенсирующие" рефакторинги
| .
| .
| .
| .
| . ** ИТ-Продукт **
| . /
| . / ◄── Резкий рост долга перед масштабированием
| . /
| . /
| . /
| . /
+----------------------------------------------> Время (итерации/релизы)
Рождение Рост Масштабирование Зрелость
```
Объяснение:
· Красная линия (ИТ-Продукт): Долг накапливается рывками (часто осознанно) в гонке за фичами. В точке «Масштабирование» происходит болезненный, но глобальный рефакторинг (часто смена архитектуры).
· Синяя линия (Финтех): Долг (в виде исключений, условных веток) накапливается постепенно и постоянно с каждым новым регуляторным требованием или интеграцией. Его невозможно «отдать» одним махом из-за рисков. Поэтому требуются плановые, локализованные мероприятия по «расчистке» (зелёные точки), не затрагивающие ядро.
График 2: Баланс «Чистота vs Устойчивость» в зависимости от критичности модуля
```
Важность "чистоты" кода
^
| Модуль А Модуль Б Модуль В Модуль Г
| (Интерфейс) (Логика (Ядро расчёта) (Интеграция
| отчётности) с брокером)
|
Выс | ВАЖНО КРИТИЧНО ОЧЕНЬ НЕВАЖНО
| КРИТИЧНО
|
Ср | * * * * * * * * * * * * * * * * * * * *
|
Низ | НЕВАЖНО НЕВАЖНО ОЧЕНЬ КРИТИЧНО
| КРИТИЧНО
+----------------------------------------------------------------->
Низкая Высокая
Важность "устойчивости" (надёжности, соответствия)
```
Матрица принятия рествурна:
· Модуль В (Ядро расчёта): Здесь нужна максимальная устойчивость и предсказуемость. Чистота кода — инструмент для этого. Допустимы только самые проверенные, «консервативные» паттерны.
· Модуль Г (Интеграция): Устойчивость к внешнему хаосу — ключевое. Код может быть «грязным» (full of try-catch, fallbacks, manual correction hooks), но процесс должен быть отказоустойчивым.
· Модуль А (Интерфейс): Можно позволить больше «чистоты» и современных практик, так как ошибка здесь реже ведёт к финансовым потерям.
· Модуль Б (Логика отчётности): Гибрид. Чистота важна для проверки логики, но устойчивость (точность) важнее всего.
Раздел 4: Сводная рабочая схема (Памятка архитектора)
Принцип 1: Стратификация по уровню риска
Разделите систему на страты (слои) с разными требованиями:
1. Ядро (Core): Расчеты, учетные операции. Требует максимальной чистоты как гарантии устойчивости. Изменения — только через формализованные реквесты, регресс-тесты.
2. Бизнес-логика (Business Logic): Правила, workflows. Допускает контролируемую «грязь» в виде условных веток для новых требований. Обязательно версионирование.
3. Интерфейсный слой (Integration/API): «Буферная зона». Строится по принципу Circuit Breaker и Dead Letter Queue. Здесь «грязь» (повторы, парсинг) — норма.
4. Данные (Data Layer):
· Оперативные: Могут быть нормализованы.
· Исторические/Аудитные: Денормализованы, неизменяемы (append-only). Снимки состояний на дату — это норма.
Принцип 2: «Управляемый технический долг»
· Каждое отклонение от «чистого» пути (костыль, дублирование) должно быть оформлено как задача технического долга.
· Задача должна иметь бизнес-обоснование (например, «Патч для выполнения указания ЦБ №XXX до 01.10.2024»).
· В продуктивном коде — оставлять метки-напоминания (// TECHDEBT-2024-001: Временное решение из-за изменений API Банка X).
Принцип 3: Дисциплина вместо идеальности
· Единый лог изменений: Каждая правка в Core-слое должна быть связана с номером требования (JIRA, Bitrix).
· Контрольные точки (Checkpoints): Перед закрытием операционного дня, перед формированием регуляторной отчётности — система делает снимок ключевых контрольных сумм.
· Воспроизводимость как критерий: Любой расчёт за любой прошлый день должен быть воспроизведён с тем же результатом. Это важнее красоты схемы БД.
Заключение
Финансовые системы — это не олимпийские объекты, которые должны поражать эстетикой. Это больше похоже на атомные электростанции или мосты: их ценность определяется не красотой чертежей, а абсолютной надежностью, предсказуемостью и способностью выдерживать экстремальные нагрузки (изменения регулятора, рыночные обвалы, человеческие ошибки).
Идеальная архитектура финтех-системы — это не та, что описана в книгах Мартина Фаулера, а та, которая:
1. Позволяет локализовать хаос от внешнего мира.
2. Обеспечивает полную прослеживаемость любой операции.
3. Даёт возможность без паники принимать срочные изменения бизнеса и регулятора.
4. Не деградирует со временем от накопленных «компромиссов» благодаря дисциплине и плановому обслуживанию.
В этом и есть её профессиональная красота.
#Финтех #Архитектура #Разработка #1C #Enterprise #RiskManagement #Регуляторика #ТехническийДолг #Инвестиции #БэкОфис #Программирование #ИТ #Финансы #Надёжность #Audit #Интеграции