Когда задача становится актуальной
- Одно значение вручную исправляют в нескольких программах.
- Непонятно, какому статусу заказа доверять.
- Каждая новая интеграция требует менять соседние связи.
- Доступность отдельного сервиса останавливает несвязанные операции.
Разделить функции и источники данных
Сначала описываются бизнес-объекты: клиент, договор, заказ, услуга, ресурс, платёж. Затем для каждого определяется система, в которой возникает подтверждённое состояние. Источники могут различаться по типу сведений: CRM ведёт коммуникацию, учётная система — документы, сервис бронирования — занятость ресурса.
Важно определить право изменения данных. Если два инструмента могут независимо менять одни условия заказа, требуется правило разрешения противоречия. Иногда достаточно ограничить одну сторону просмотром; иногда нужна передача запроса на изменение владельцу данных. Архитектура фиксирует эти решения до выбора конкретного способа обмена.
Проектировать связи по событиям процесса
Интеграция должна передавать событие или сведения с понятным назначением. Для каждого обмена определяем отправителя, получателя, состав данных и ожидаемое действие. Отдельно описываем допустимую задержку, повторную передачу и способ обнаружить незавершённую операцию. Эти условия зависят от процесса и возможностей подключаемых систем.
Доступы проектируются по ролям и назначению сервиса. Не каждой системе нужны полные данные клиента, а каждому сотруднику — полный административный доступ. В архитектуре отражается, какие сведения необходимы для конкретного действия и где сохраняется история изменений. Это облегчает контроль и уменьшает неоднозначность ответственности.
| Архитектурное решение | Что нужно определить | Практическое следствие |
|---|---|---|
| Владелец данных | Где подтверждается значение | Понятно, откуда исправлять ошибку |
| Граница системы | Какие функции она выполняет | Разработка не дублирует существующую логику |
| Событие обмена | Что запускает передачу | Состояния изменяются согласованно |
| Недоступность связи | Что ждёт, что продолжает работать | Сбой виден и имеет порядок восстановления |
Пример архитектуры заказа услуги
Обращение поступает с сайта в CRM. После согласования создаётся заказ, учётная система готовит предусмотренные документы, а кабинет клиента показывает подтверждённые этапы. Источник каждого статуса определён заранее: интерфейс кабинета не придумывает состояние на основе косвенных признаков.
Исключение — связь с учётной системой временно недоступна. Заказ сохраняется в исходной системе, операция обмена имеет отдельное состояние ожидания, а ответственная роль видит причину. Повторная передача использует идентификатор того же заказа. Архитектура определяет, какие действия можно продолжить и какие требуют подтверждения, не смешивая сбой обмена с отказом в исполнении заказа.
Выбрать реализацию и последовательность развития
Варианты сопоставляются по поддержке процессов, доступности интеграций, ограничениям лицензий, сложности сопровождения и возможности развития. Готовый сервис, настройка действующей платформы и собственный компонент могут сочетаться. Выбор должен объяснять, какую функцию закрывает каждый элемент и от каких внешних условий зависит его работа.
Переход к целевой архитектуре планируется с учётом действующих операций. Определяем, какие данные нужно подготовить, где потребуется временный обмен и когда старый источник перестаёт использоваться. Приёмка включает обычные сценарии, восстановление после ошибок и проверку прав. Документы архитектуры остаются связаны с реальными конфигурациями, чтобы следующие изменения можно было оценивать на актуальной основе.
Что получит компания
- Карта действующих и целевых систем с назначением.
- Модель бизнес-объектов и владельцев данных.
- Схема обменов, событий и обработки ошибок.
- Требования к ролям, доступам и истории действий.
- Последовательность перехода и критерии проверки.
Что подготовить к обсуждению
- Перечень систем, конфигураций и лицензий.
- Основные процессы и планы развития.
- Обезличенные примеры объектов и противоречащих данных.
- Доступная документация API и действующих интеграций.
Вопросы о проекте
Нужно ли объединить всё в одну программу?
Единый процесс может поддерживаться несколькими специализированными системами. Важно согласовать их функции, данные и взаимодействия. Решение об объединении принимается по ограничениям и стоимости развития, а не по количеству программ само по себе.
Можно ли спроектировать архитектуру без выбора поставщиков?
Сначала можно определить функции, объекты и требования независимо от продуктов. Затем варианты проверяются на конкретных системах. Для рабочих интеграций необходимо подтвердить возможности API, прав и конфигураций выбранных инструментов.
Что влияет на объём проектирования?
Число систем, сложность обменов, качество данных и требования к непрерывности операций. Дополнительного разбора требуют скрытые ручные связи и недокументированные изменения. Архитектуру можно развивать по этапам, сохраняя согласованные границы.