Знайте свои инструменты: девять вопросов

🌐 Также доступно на 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)

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

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

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

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

Архитекторам нужно умение судить. Но суждение без знаний мало чего стоит. Свои инструменты все равно нужно знать.

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

Девять вопросов

Изучая или оценивая технологию, спрашивайте:

1. Что это такое?
2. Где это используется?
3. Как этим пользоваться?
4. Какие у меня есть альтернативы?
5. Каковы сильные стороны?
6. Каковы слабые стороны?
7. Как объяснить это разработчикам, бизнесу и руководителям?
8. Как это сопровождается в долгосрочной перспективе?
9. Сколько это стоит, какие лицензии нужны и каковы лимиты?

Если вы можете ответить на все девять, вы начинаете понимать инструмент как архитектор. Обратите внимание, чего в списке нет: «Могу ли я это настроить?» Это важно, но это лишь часть знания инструмента.

Click to enlarge

1. Что это такое?

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

2. Где это используется?

Знать, что что-то делает, — не то же самое, что знать, когда этому место в архитектуре. С какими задачами это хорошо справляется? При каких условиях это уместно и какие условия должны вызвать у меня подозрение? Это шаг от «я знаю эту функцию» к «я узнаю проблему, которую эта функция решает», и это большой шаг. Не нужно ходить и искать, куда бы применить любимую технологию. Нужно распознавать проблемы и знать, какие инструменты к ним подходят.

3. Как этим пользоваться?

Да, архитекторы должны понимать реализацию. Вам не нужно строить каждый компонент, но вы должны понимать достаточно, чтобы знать, что просите построить других. Знайте, как это настраивается, как с этим работает разработчик, как данные попадают внутрь и выходят наружу, как это развертывается и защищается и как это выглядит в эксплуатации. Я не хочу, чтобы архитектор проектировал вокруг технологии, которую видел только на продуктовом слайде. Запачкайте руки: постройте что-нибудь, сломайте что-нибудь, посмотрите, как оно ведет себя на самом деле. Архитектура становится лучше, когда опирается на реальность.

4. Какие у меня есть альтернативы?

Возможно, это самый важный вопрос в списке. Если вы знаете только один способ решить задачу, у вас нет архитектурного решения; у вас есть вариант по умолчанию. Когда кто-то предлагает технологию, я хочу знать, что еще мы могли бы сделать. Другая возможность Salesforce? Что-то декларативное или код? Может ли эта возможность жить вне Salesforce? Можем ли мы оставить данные на месте вместо копирования, использовать событие вместо вызова API или вообще ничего не строить? Альтернативы создают компромиссы, а компромиссы — сердце архитектуры.

5. Каковы сильные стороны?

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

6. Каковы слабые стороны?

Это не менее важно. У каждой технологии есть слабые стороны, у каждой. Если кто-то может рассказать вам только о сильных сторонах технологии, архитектурного обсуждения у вас пока нет. С чем она плохо справляется? Где появляется сложность и что происходит в масштабе? Какую эксплуатационную нагрузку и зависимости она приносит? Какие требования выталкивают ее из зоны, где она сильнее всего? Слабая сторона не всегда значит, что технологию не стоит использовать. Она значит, что нам нужно знать, что мы принимаем. Компромисс, который вы понимаете, может быть архитектурным решением. Компромисс, которого вы не понимаете, может стать сюрпризом.

7. Как объяснить это разным аудиториям?

Это один из вопросов, которые отделяют технические знания от архитектурного мастерства. Можете ли вы объяснить одну и ту же технологию разработчику, бизнесу и руководителю? Это не должно быть одно и то же объяснение. Разработчику нужны API, поведение транзакций, безопасность, обработка сбоев и шаблоны реализации. Бизнесу важно, что это дает и как меняется их процесс. Руководителю важны стоимость, риски, сроки, влияние на организацию и какие варианты решение оставляет открытыми или закрывает. Вы не меняете правду; вы меняете уровень абстракции. Если вы можете объяснить технологию только словами ее документации, продолжайте работать над своим пониманием.

8. Как это сопровождается в долгосрочной перспективе?

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

9. Сколько это стоит, какие лицензии нужны и каковы лимиты?

Это вопрос, который я добавил к исходным восьми, и сегодня я считаю, что без него никак. Технология может быть идеальным техническим решением и при этом неправильным архитектурным, если не сходится экономика. Входит ли она в лицензии, которые у нас есть, или это дополнение? Лицензируется ли она по пользователям, использованию, потреблению, хранилищу или транзакциям? Что происходит со стоимостью при масштабировании?

Дальше — лимиты, и они есть у каждой платформы: лимиты API, хранилища, запросов, транзакций, параллелизма, пропускной способности и лицензий. Одни жесткие, другие мягкие; одни можно поднять, другие нет; некоторые не имеют значения при нашем масштабе, пока мы не добавим еще один ноль. Не нужно заучивать каждый лимит Salesforce, это было бы ужасной тратой вашего времени. Нужно знать, что лимиты существуют, какие из них важны для вашей архитектуры и когда пора пойти и проверить актуальную цифру. Цифры будут меняться. Архитектурный вопрос остается.

Разобранный пример: Apex sharing

Вот один из моих самых частых примеров того, как работают эти вопросы. Нам приходит требование сложного общего доступа, которое невозможно реализовать никакими правилами общего доступа на основе владельца или критериев. Это приводит нас к Apex sharing: коду, который сам записывает записи общего доступа. Теперь нам нужно знать, что такое Apex sharing, где он используется, как им пользоваться и все остальное. Это эскалация: Apex sharing — альтернатива (вопрос 4) для случаев, когда нужные нам правила выходят за пределы того, что можно выразить общим доступом на основе владельца и критериев.

Теперь его слабые стороны (вопрос 6). Допустим, у нас клиентское сообщество с 10 или 20 млн участников, и мы используем лицензию Customer Community, а не Customer Community Plus. Это пользователи с большим объемом (high-volume users). У них нет ролей, и они вообще не используют модель общего доступа: их доступ определяется наборами общего доступа (sharing sets) и группами общего доступа (share groups), сопоставляемыми через их организацию и контакт. Для них нет записи общего доступа, которую мог бы записать Apex, поэтому Apex sharing для них не работает. И привел нас сюда как раз вопрос о стоимости и лицензиях (вопрос 9): выбор лицензии определил, какие инструменты общего доступа вообще существуют.

Так что, как Apex sharing был альтернативой правилам на основе владельца и критериев, вы можете столкнуться со случаем, когда нужна альтернатива уже самому Apex sharing. А на этом этапе вариантов на основе настройки для сложных правил общего доступа на самом деле нет. В итоге вы делаете объект доступным только для чтения и управляете доступом через Apex. Вот почему все девять вопросов нужно задать до выбора, а не после.

Не заучивайте платформу

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

Я хочу, чтобы вы выработали схему обучения. Когда Salesforce завтра выпустит новую возможность, мне не нужно было видеть ее раньше. Я знаю, что спрашивать: что это, где это уместно, как этим пользоваться, что еще я мог бы использовать, в чем это хорошо, где с этим трудно, как это объяснить, как это эксплуатировать, сколько это стоит и где лимиты? Теперь я могу начать это оценивать. Это гораздо ценнее, чем заучивать очередную матрицу функций.

За пределами экзамена: с ИИ на девять вопросов отвечать быстрее, но и ошибиться легче. Встретив незнакомую технологию, вы можете попросить ИИ объяснить ее, сравнить три подхода, перечислить ее лимиты и типичные сбои или привести доводы против ее использования. Это замечательный помощник в исследованиях. Но он может ошибаться, отставать от жизни или уверенно путать два продукта или редакции с похожими названиями. Все, что влияет на решение, проверяйте: идите к источнику и сверяйтесь с актуальной документацией, лимитами и лицензиями. Доверяй, но проверяй (модуль 7).

Учите вопросы, а не только ответы

В этом курсе мы встретим множество технологий. Я не хочу, чтобы вы собирали ответы; я хочу, чтобы вы тренировались задавать вопросы. Когда мы будем говорить о big objects, внешних данных, Data 360, шаблонах интеграции или о возможности ИИ, которую Salesforce выпустит через полгода после того, как была написана эта глава, задавайте те же девять вопросов.

Ответы будут меняться. Вопросы долговечны. Именно это делает их архитектурной схемой, а не учебным пособием.

Знайте свои инструменты: в чем они хороши, в чем плохи, что еще можно использовать, сколько они стоят и где ломаются. И знайте достаточно, чтобы объяснить решение людям, которым с ним жить. Так архитектор изучает технологии.

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

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

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

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-09; повторно проверено 2026-10-12): у пользователей с большим объемом (лицензии External Apps, Customer Community, High Volume Customer Portal и Authenticated Website) нет ролей; их доступ определяется наборами общего доступа и группами общего доступа; их нельзя включить в правила общего доступа на основе владельца, а записи, которыми они владеют, нельзя предоставить вручную.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (на английском, проверено 2026-10-09; повторно проверено 2026-10-12): пользователи с большим объемом (Customer Community, High Volume Customer Portal, Authenticated Website) не используют модель общего доступа, потому что их лицензии не поддерживают роли; доступ работает через сопоставление пользователя с полями lookup на организацию и контакт, с помощью наборов общего доступа или групп общего доступа. На той же странице перечислено, когда Apex managed sharing — правильный инструмент.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), вопрос в Trailblazer Community, ноябрь 2024 г. (на английском, проверено 2026-10-09; повторно проверено 2026-10-12): практик сообщает, что вставка записей общего доступа для пользователей с большим объемом завершилась ошибкой. Это отчет с практики, а не официальная документация. (Онлайн-сообщество Trailblazer Community станет доступным только для чтения 30 октября 2026 г.; ссылка может измениться.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-09): набор общего доступа предоставляет доступ к записям, связанным с организацией или контактом пользователя.