Тест на обратимость

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 3 из 7 главы Думать как архитектор данных, глава 1 курса Data Architect. Каждый модуль самостоятелен. Назад: Модель данных — это скелет · Далее: Архитектура — искусство компромиссов

Вопрос, на который отвечает этот модуль: Как отличить архитектурное решение от обычного?

Архитекторы принимают много решений.

Но не каждое решение — архитектурное.

Это важное различие. Если считать архитектурой каждое решение, мы потратим все время на споры о вещах, которые относительно легко изменить. А если не распознать решения, которые действительно архитектурные, можно сегодня за пять минут принять решение, на распутывание которого уйдет пять лет.

Так как же отличить одно от другого?

Я люблю задавать простой вопрос:

Насколько трудно будет потом отменить это решение?

Я называю это тестом на обратимость (Reversibility Test).

Чем труднее что-то отменить и чем больше от этого будет зависеть, тем больше архитектурного внимания это заслуживает.

Некоторые решения дешево изменить

Начнем с простого.

Мы называем поле Customer Category («Категория клиента»). Через полгода бизнес решает, что на самом деле все называют это Customer Segment («Сегмент клиента»). Мы меняем метку. Возможно, придется обновить документацию и немного переобучить пользователей, но это не крупное архитектурное событие. Правда, с исходным API-именем придется жить, потому что его изменение влечет гораздо более серьезные последствия. Так что, возможно, речь просто о смене метки и о путанице, которая может с ней прийти.

Мы приняли решение. Мы передумали. Мы пошли дальше.

А теперь сравните это с другим решением.

Мы создаем идентификатор для клиентов. Мы решаем, что он означает, какой у него формат и какая система его создает. Потом мы его публикуем.

Его использует Salesforce. Его использует хранилище данных. Его использует интеграционная платформа. Его использует клиентский портал. Еще пять приложений начинают его хранить. Его используют отчеты и конвейеры данных. Может быть, со временем его увидят и клиенты.

Через три года кто-то говорит:

Пожалуй, не стоило проектировать идентификатор именно так.

Это уже совсем другой разговор.

Разница не в том, что одно решение более техническое, чем другое.

Разница в обратимости.

Вот как это может случиться. Допустим, бизнес строил свои ключи из части имени клиента плюс номер. Годами это работает, потому что никому ни разу не пришлось менять имя. А потом, через год или больше, имя все-таки меняется, и внезапно ключи перестают соответствовать шаблону, которого ожидают остальные данные. Это одна из причин, почему ключи не должны нести никакого собственного смысла.

Архитектура создает гравитацию

Архитектурное решение, как правило, обрастает вещами вокруг себя. Я думаю об этом как о гравитации.

Выберите объектную модель — и вокруг нее строится автоматизация.

Выберите ключ — и другие системы начинают его хранить.

Выберите, где живут мастер-данные, — и интеграции начинают течь к ним и от них.

Выберите модель общего доступа — и бизнес-процессы начинают зависеть от того, кто что видит.

Выберите шаблон интеграции — и системы начинают зависеть от его сроков и поведения.

Чем дольше существуют эти решения, тем сильнее их гравитация. В конце концов изменить исходное решение значит изменить все, что накопилось вокруг него.

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

Вот почему важно, что модель данных — это «скелет». Мы осторожны не потому, что изменения — это плохо. Мы осторожны, потому что зависимости делают изменения дорогими.

Задайте два вопроса

Когда я смотрю на проектное решение, я задаю два вопроса:

Насколько трудно это отменить?

Сколько всего будет от этого зависеть?

Они связаны, но не одинаковы. Что-то может быть технически легко изменить, но у него сотни потребителей. Раньше стандартные объекты часто переименовывали для ясности — скажем, организацию (Account) в «Клиента». Сделать легко. Потом другая система захотела использовать организации для партнеров — и не смогла. А у чего-то другого может быть всего несколько потребителей, но для изменения нужна огромная миграция, например API-имя объекта, на которое много ссылок внутри. Снаружи его никто не видит, но неудачное имя постоянно путает команду. И то и другое заслуживает внимания.

Подумайте о некоторых типичных решениях по данным:

• Какой объект Salesforce представляет это бизнес-понятие?
• Что является уникальным идентификатором?
• Какая система является системой записи (system of record)?
• Копируются ли эти данные в Salesforce или к ним обращаются где-то еще?
• Это один объект или несколько связанных объектов?
• Кто владеет данными и как долго мы их храним?
• Каковы наши границы доступа по умолчанию?
• Как эти данные перемещаются между системами?

Это совсем не то же самое, что решать, где поле появится на странице Lightning. Дизайн страницы тоже важен. Но цена ошибки другая.

Click to enlarge

Думайте о радиусе поражения

Еще один способ думать об обратимости — радиус поражения (blast radius): если я изменю это решение, что еще сдвинется?

Допустим, то, что мы смоделировали как поле, на самом деле должно стать дочерним объектом. Это не просто изменение схемы. Что будет с существующими данными? С отчетами, интеграциями, которые ждут это поле, с Apex и Flows, которые на него ссылаются, с безопасностью, аналитикой, с ИИ-агентом, чьи действия зависят от исходной структуры?

Чем больше радиус, тем внимательнее нужно принимать исходное решение.

Вот почему архитекторы должны смотреть дальше своей части системы. Изнутри Salesforce изменение может выглядеть простым. С уровня предприятия оно может затронуть двенадцать других систем.

Решения предприятия и решения Salesforce

Архитектор данных думает на двух уровнях.

Внутри Salesforce мы решаем, какие будут объекты, связи, ключи, объем, доступ, автоматизация и как данные ведут себя на платформе.

На уровне всего предприятия мы задаем более широкие вопросы. Где на самом деле живет клиент? Кто владеет продуктом? Какая система создает заказ? Какой у нас авторитетный идентификатор? Какая информация копируется между системами, а какая остается там, где есть?

Эти два уровня должны быть связаны. Я видел внедрения Salesforce, где внутренняя модель сама по себе была совершенно логичной, но не вписывалась в окружающее предприятие. Этого недостаточно. Структуры Salesforce должны быть отражены на уровне предприятия, а решения предприятия должны возвращаться в Salesforce.

Архитектура — это двустороннее движение.

Click to enlarge

Притормозите перед дорогими решениями

Одна из опасностей в технологиях в том, что решения, которые проще всего реализовать, могут казаться решениями, которые проще всего принять. Это не одно и то же.

Создать еще один пользовательский объект легко. Создать еще одно поле легко. Подключить еще один API становится все легче, а ИИ делает все это еще проще.

Но простота реализации почти ничего не говорит о цене архитектурного решения.

Перед решением, которое трудно отменить, притормозите достаточно, чтобы спросить: какую проблему мы на самом деле решаем? Какие альтернативы мы рассмотрели? Что мы предполагаем? Что будет с ростом объема и с изменениями в бизнесе? Что еще будет от этого зависеть? Что будет, если мы ошибаемся?

Нам не нужны полгода ревью каждый раз, когда мы создаем объект. Но нужно обдумывание, соразмерное цене ошибки. Если это объект для одного отдела или подсистемы, можно двигаться быстрее. Если это справочные данные, ключевой объект клиента или что-то, что используется в нескольких системах, не пожалейте времени, чтобы все продумать.

Запишите почему

С важными решениями есть еще одна проблема: люди забывают, почему они были приняты.

Кто-то смотрит на архитектуру через три года и спрашивает: «Ну зачем кто-то так это спроектировал?» Иногда ответ — это был плохой проект. Такое бывает. Но иногда для этого была очень веская причина: ограничение платформы, которого больше нет, регуляторное требование, другая система, которая не поддерживала предпочтительный подход, компромисс, сознательно принятый ради дедлайна.

Если мы записываем только что решили, а не почему, следующему архитектору неоткуда это узнать.

Для значимых решений записывайте. Это не должен быть 50-страничный документ. Полезная запись о решении может быть совсем маленькой:

Контекст: Какую проблему мы решаем?

Варианты: Какие реалистичные альтернативы мы рассмотрели?

Решение: Что мы выбрали?

Последствия: Что мы получаем и от чего отказываемся?

Владелец: Кто отвечает за это решение?

Пересмотр: Какая причина или дата должна заставить нас вернуться к нему?

Ценность не в документе. Ценность в сохранении рассуждений.

А когда решение меняется, не стирайте исходное. Замените его новым. Решение, которое было правильным в 2027 году, может оказаться неправильным в 2030-м, потому что меняются объемы, бизнес, Salesforce и наше понимание. Я хочу сохранить историю: вот был контекст, вот было решение и почему, вот что изменилось, и вот что мы решаем сейчас. Это гораздо ценнее, чем делать вид, будто мы всегда знали ответ.

Click to enlarge

За пределами экзамена: ИИ сокращает время от решения до зависимости. ИИ-инструмент может за секунды предложить модель данных, а затем создать поверх нее объекты, автоматизацию, интеграционный код и пользовательский интерфейс. Раньше от сомнительного решения начинало что-то серьезно зависеть только после месяцев разработки; теперь зависимости появляются почти сразу. Поэтому проверяйте решения, лежащие под результатом, а не только сам результат. ИИ может помочь: перечислить варианты, оспорить предположения и набросать запись о решении. Но решает по-прежнему архитектор, и чем труднее решение отменить, тем важнее человеческое суждение.

Знайте, какие решения важны

Один из навыков, которые я хочу у вас развить, — понимать, на что тратить внимание.

Не превращайте каждый выбор настройки в архитектурный саммит.

Но и не принимайте мимоходом решение, с которым организация будет жить следующее десятилетие.

Спросите:

Насколько трудно будет это отменить?

Сколько всего будет от этого зависеть?

Если ответы — очень трудно и много, вы, скорее всего, нашли архитектурное решение.

Click to enlarge

Притормозите. Поймите требование. Изучите альтернативы. Сделайте компромиссы видимыми. Примите решение. И запишите почему.

Цель архитектуры — не принимать решения, которые никогда нельзя изменить.

Цель — распознавать решения, где передумать будет дорого.

Что здесь решает архитектор

• Какие решения архитектурные: их трудно отменить, и от них многое зависит.
• Сколько внимания получает каждое решение — соразмерно цене ошибки.
• Какие решения записываются — с контекстом, вариантами, последствиями, владельцем и точкой пересмотра.
• Как решения в Salesforce согласуются с решениями предприятия.

Дополнительно

• Object Relationships Overview (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-09; повторно проверено 2026-10-12): в связи master-detail доступ и владение дочерней записи следуют за главной, а удаление главной записи удаляет ее дочерние.
• Considerations for Object Relationships (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-09; повторно проверено 2026-10-12): связь lookup преобразуется в master-detail, только если у каждой записи в ней есть значение; преобразование меняет модель общего доступа (на Controlled by Parent), а тип связи определяет, какие стандартные типы отчетов доступны.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-09; повторно проверено 2026-10-12): поля сводки (roll-up summary) существуют только в связях master-detail, и их нужно удалить, прежде чем master-detail можно превратить в lookup.