Архитектура корпоративных систем: как проектировать ПО, которое живёт 10–15 лет

Автор: Инженер-программист

Практическое руководство с чек-листами, примерами и расчётами

Почему традиционный подход больше не работает

Конкретные цифры проблемы:

• Стоимость senior-разработчика: 400–600 тыс. руб./мес (2025)
• Срок выхода на продуктивность нового разработчика в legacy-коде: 4–6 месяцев
• Типичный time-to-market для изменений в монолите: 3–6 месяцев
• Стоимость часа простоя критичной системы: от 500 тыс. руб. и выше

Реальный кейс: Банк разрабатывал новый модуль кредитования «с нуля» на микросервисах. Бюджет: 45 млн руб., срок: 9 месяцев. Результат через год: работает только базовый флоу, команда из 12 человек постоянно тушит инциденты, бизнес недоволен.

Альтернативный сценарий с гибридной архитектурой:

• Ядро расчётов: 2–3 месяца на Java (3 разработчика)
• UI и workflow: low-code платформа (1 разработчик + аналитик)
• Интеграции: iPaaS (настройка, не код)
• Бюджет: 15 млн руб., время: 4 месяца

---

Модульный монолит + платформенный слой: пошаговая схема

Шаг 1: Картирование зон ответственности

Практическая матрица разделения:

Зона системы	Технология	Критерий выбора	Пример
Расчётное ядро	Код (Java/C#/Go)	Сложность > 5 условий, performance-критично	Расчёт кредитного скоринга
Бизнес-процессы	BPM/Low-code	Часто меняются, > 3 участников	Согласование договора
Пользовательские формы	Low-code UI	Нет сложной логики	Заявка на отпуск
Интеграции	iPaaS	Синхронные вызовы, < 1000 тр/сек	Получение данных из SAP
Отчёты	BI/Low-code	Агрегация, визуализация	Ежемесячный дашборд

Шаг 2: Проектирование bounded contexts

Чек-лист для выделения контекста:

• Имеет чёткую бизнес-границу (например, «Управление договорами»)
• Может работать автономно 80% времени
• Изменения не требуют синхронизации с 5+ другими командами
• Имеет не более 3–5 ключевых сущностей
• Владеет своими данными (отдельная схема БД)

Пример контекста «Кредитование»:

[Контекст: Кредитование]
│
├── Ядро (код)
│   ├── Расчёт платежей
│   ├── Скоринг
│   └── Управление лимитами
│
├── Платформенный слой
│   ├── BPM: процесс согласования
│   ├── Low-code UI: кабинет клиента
│   └── iPaaS: интеграция с бюро кредитных историй
│
└── API (входы/выходы)
    ├── REST: создать заявку
    ├── Events: заявка одобрена
    └── Webhooks: смена статуса

Шаг 3: Установка архитектурных правил

Запреты (фиксируются документально):

1. Low-code НЕ ИМЕЕТ прямого доступа к БД ядра
2. BPM НЕ СОДЕРЖИТ расчётной логики (только оркестрация)
3. Интеграции НЕ ИДУТ напрямую между контекстами (только через шину/API)
4. UI-формы НЕ СОДЕРЖАТ бизнес-правил (только валидация)

Разрешения:

1. Low-code МОЖЕТ создавать новые формы без согласования архитектора
2. BPM МОЖЕТ менять маршруты согласования без релиза кода
3. Аналитик МОЖЕТ создавать отчёты самостоятельно

---

Low-code как архитектурный слой: инструкция по применению

Сценарий 1: Быстрый MVP для нового продукта

Задача: Запустить программу лояльности за 1 месяц с бюджетом 2 млн руб.

Решение:

1. Неделя 1: Проектирование данных (PostgreSQL, 3 таблицы)
2. Неделя 2–3: Low-code UI (Appsmith/Retool)
   • Форма регистрации участника
   • Личный кабинет с историей бонусов
   • Админ-панель для операторов
3. Неделя 4: Интеграция через iPaaS
   • Webhook от кассовой системы → начисление бонусов
   • Email-уведомления (SendGrid)

Результат: Работающий продукт, 0 строк кастомного кода, легко передать бизнесу для доработок.

Когда переходить на код:

• Если пользователей > 50 тыс. и возникают проблемы с производительностью
• Если появляется сложная логика расчёта бонусов (многоуровневые правила)

Сценарий 2: Оркестрация процесса согласования

Задача: Автоматизировать согласование закупок с 7 этапами и 15 типами участников.

Антипаттерн (код):

java

// 500 строк if-else, которые никто не хочет менять
if (amount > 100000 && department.equals("IT")) {
    if (hasContract) {
        approvers.add(cfo);
    } else {
        approvers.add(ceo);
        approvers.add(legalHead);
    }
}
// ... ещё 400 строк
```

**Правильно (BPM):**
- Графическая BPMN-схема с ветвлениями
- Бизнес-аналитик меняет правила без программистов
- История версий процесса
- Аудит каждого прохода

**Экономика:**
- Изменение в коде: 3 дня (разработка + тестирование + деплой)
- Изменение в BPM: 2 часа (правка схемы + тестирование)

### Сценарий 3: Интеграционный слой

**Задача:** Получать данные о клиентах из CRM, обогащать из внешних источников, передавать в 5 систем.

**Решение с iPaaS (например, n8n, Zapier, Make):**
```
Триггер: новый клиент в CRM
  ↓
Шаг 1: Получить данные клиента (API CRM)
  ↓
Шаг 2: Обогатить (внешний сервис проверки ИНН)
  ↓
Шаг 3: Параллельно отправить в:
  - ERP (создать контрагента)
  - Система документооборота (создать папку)
  - Email-рассылка (добавить в сегмент)
  - BI (записать в витрину)
  - 1С (синхронизация)
```

**Преимущества:**
- Визуальная настройка без кода
- Встроенные коннекторы к популярным системам
- Логирование и retry из коробки
- Стоимость лицензии: 50–200 тыс. руб./год vs. 3–5 млн руб. разработки

---

## Архитектура как актив: практические инструменты

### Инструмент 1: Карта контекстов (Context Map)

**Шаблон для заполнения:**
```
[Контекст A] ---(отношение)---> [Контекст B]

Типы отношений:
- Partnership: равноправное взаимодействие
- Customer/Supplier: один контекст зависит от другого
- Conformist: один полностью подчиняется модели другого
- Anticorruption Layer: защитный слой от чужой модели
```

**Пример для ритейла:**
```
[Каталог товаров] ---(Supplier)---> [Заказы]
[Заказы] ---(Customer)---> [Доставка]
[CRM] ---(Anticorruption)---> [Заказы]
  (CRM — legacy, используем адаптер)

Инструмент 2: Decision Records (ADR)

Шаблон записи архитектурного решения:

markdown

# ADR-042: Использование BPM для процесса закупок

## Статус
Принято (2025-01-15)

## Контекст
Процесс согласования закупок меняется 3–4 раза в год.
Текущая реализация в коде требует 2 недели на изменение.

## Решение
Перенести логику маршрутизации в Camunda BPM.

## Последствия
+ Изменения за 1 день силами аналитика
+ Визуальная схема для аудита
- Зависимость от платформы Camunda
- Необходимость обучения команды BPMN

## Альтернативы
1. State Machine в коде — отвергнуто (слишком долгие изменения)
2. Rule Engine (Drools) — отвергнуто (избыточная сложность)

Инструмент 3: Матрица технологических ограничений

Для каждого слоя системы:

Слой	Разрешено	Запрещено	Исключения
Ядро	Java 17+, Spring Boot	Reflection, eval()	Только для маппинга JSON
BPM	Camunda	Groovy-скрипты > 10 строк	Только справочные проверки
Low-code UI	Retool	Прямые SQL-запросы	Только readonly к витринам
iPaaS	n8n	Custom Node.js код	Только для форматирования

---

Чек-лист перехода к гибридной архитектуре

Месяц 1: Аудит и планирование

• Провести event storming для выявления контекстов
• Составить список процессов, которые меняются чаще 1 раза в квартал
• Выбрать 1–2 пилотных контекста для гибридизации
• Оценить текущие инструменты (BPM/Low-code/iPaaS)

Месяц 2–3: Пилот

• Выделить 1 bounded context (например, «Заявки»)
• Перенести UI на low-code платформу
• Перенести workflow на BPM
• Обернуть существующий код в REST API
• Настроить мониторинг и логирование

Месяц 4–6: Масштабирование

• Документировать паттерны и best practices
• Обучить команду (workshop по BPMN, low-code)
• Внедрить ADR для новых решений
• Перевести 2–3 дополнительных контекста
• Настроить автоматические проверки границ (ArchUnit тесты)

---

Антипаттерны и как их избежать

Антипаттерн 1: «Low-code везде»

Симптомы:

• Бизнес-логика размазана по формам и workflow
• Производительность проседает на 10 тыс.+ пользователях
• Невозможно покрыть тестами

Лечение: Вынести всю логику в код, оставить в low-code только UI и оркестрацию.

Антипаттерн 2: «Микросервисы + low-code»

Симптомы:

• 30 микросервисов + 15 low-code приложений
• Никто не понимает, где какая логика
• Деплоймент занимает 2 дня

Лечение: Консолидировать в модульный монолит, low-code использовать только как фронт.

Антипаттерн 3: «Архитектура без правил»

Симптомы:

• Каждая команда использует свой подход
• Интеграции идут напрямую между системами
• Нет единого логирования и мониторинга

Лечение: Внедрить Technology Radar, создать архитектурный комитет, зафиксировать правила в ADR.

---

Метрики успеха гибридной архитектуры

Измеряйте:

1. Time-to-market для изменений
   • Цель: < 1 недели для бизнес-процессов
   • Цель: < 1 месяца для ядра
2. Стоимость владения
   • Цель: снижение на 30% за год
3. Bus factor
   • Цель: каждый контекст понятен минимум 3 людям
4. Доля автоматизированных тестов
   • Цель: > 70% для кода ядра
5. Доля изменений без релиза
   • Цель: > 60% (за счёт low-code/BPM)

---

Заключение: roadmap на первые 6 месяцев

Неделя 1–2: Обучение команды (DDD, BPMN, low-code)
Неделя 3–4: Event storming, выделение контекстов
Месяц 2: Пилот на 1 контексте
Месяц 3: Документирование, ADR, правила
Месяц 4–6: Масштабирование на 3–5 контекстов

Главный принцип:
Архитектура должна упрощать изменения, а не усложнять их. Low-code ускоряет там, где это безопасно. Код фиксирует то, что не должно меняться каждую неделю.

---

Дополнительные материалы:

• Шаблоны ADR: https://adr.github.io
• Context Mapping: https://github.com/ddd-crew/context-mapping
• Technology Radar: https://www.thoughtworks.com/radar