Думать как архитектор данных
Также доступно на 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)
Учебное пособие к главе 1 курса Data Architect. Сначала прочитайте семь модулей; эта страница поможет проверить, что запомнилось.
Об этом учебном пособии. Оно построено только на собственных материалах этого курса и на списке целей из опубликованного руководства Salesforce по экзамену. Оно никогда не основано на настоящих экзаменационных вопросах и не претендует на знание того, что будет на экзамене. Если вы сдавали экзамен, пожалуйста, не присылайте мне вопросы из него: сертификационное соглашение запрещает ими делиться, да и заучивание ответов — неправильный путь к тому, чтобы стать архитектором.
В этой главе меньше экзаменационных фактов, и это сделано намеренно. Она о том, как думает архитектор, и ни одна экзаменационная цель не принадлежит только ей. Но экзамен построен на сценариях: бизнес, несколько цифр, ограничение и несколько ответов, которые могли бы подойти. Привычки из этой главы — это то, как вы читаете такие сценарии. Поэтому в чек-листе ниже указано, какую цель поддерживает каждый пункт, а не утверждается, что он проверяется напрямую.
Для экзамена
Заголовок раздела «Для экзамена »Отмечайте пункты по мере продвижения. Каждый ведет туда, где он объясняется.
Читать сценарий как архитектор (поддерживает все цели)
- Я отделяю настоящее требование от проекта решения, в котором оно пришло («нам нужны поля „Согласующий 2“ и „Согласующий 3“» против «нам нужно отслеживать каждое согласование»). (Не принимайте требование на веру)
- Я ищу подразумеваемые требования, которые никто не высказал: владение, свежесть, сбои, хранение, доступ. (Ищите подразумеваемые требования)
- Я выражаю это в цифрах: объем в день, в год, с ростом, — и замечаю, когда еще один ноль меняет ответ. (Знайте свои цифры)
- Среди нескольких рабочих ответов я сравниваю, что каждый дает и чем жертвует, с учетом заявленных требований и ограничений. (Знайте, чем вы жертвуете, Ограничения меняют ответ)
- Я считаю стоимость, лицензии и лимиты частью того, подходит ли инструмент, а не чем-то второстепенным. (Девять вопросов)
Модель данных (поддерживает DM-1)
- Я могу оценить модель по тому, поддерживает ли она бизнес, может ли расти вместе с ним и хорошо ли работает. (Поддерживать. Расти. Работать.)
- Я могу распознать модель, которая слишком плоская («Поле 1», «Поле 2», «Поле 3»), чрезмерно нормализована или построена не на том стандартном объекте. (Слишком плоская, слишком сложная или просто неправильная)
- Я знаю, почему список выбора подходит для короткого стабильного списка, а lookup — для списка, который продолжает расти или приходит из интеграции. (Много способов решить задачу)
- Я знаю, что ключ, который несет смысл (например, часть имени), ломается, когда этот смысл меняется. (Некоторые решения дешево изменить)
Изменение того, что уже есть (поддерживает DM-1 и SDM-2)
- Я знаю, почему изменение типа поля или пометка существующего поля как Required (обязательное) может позже все сломать и почему платформа блокирует смену типа, пока на поле ссылаются код или flows. (Осторожнее с изменением скелета)
- Я знаю шаблон добавляйте, а не меняйте; выводите из употребления, а не удивляйте и то, что Field Usage может пометить поле как кандидата на вывод из употребления. (Осторожнее с изменением скелета)
- Я знаю факты о master-detail, стоящие за тестом на обратимость: доступ и владение дочерней записи следуют за главной, удаление главной записи удаляет дочерние, поля сводки требуют master-detail, а lookup преобразуется в master-detail, только если у каждой записи есть значение. (Тест на обратимость, «Дополнительно»)
Лицензии и общий доступ (поддерживает SDM-1)
- Я знаю, что у пользователей сообщества с большим объемом (high-volume, в том числе Customer Community) нет ролей и они не используют модель общего доступа, поэтому доступ определяется наборами общего доступа и группами общего доступа, а Apex sharing до них не дотягивается. (Разобранный пример: Apex sharing)
Сбои (поддерживает MIG-1 и главы об интеграции)
- Я знаю, что «задание завершено» — не то же самое, что данные верны, и как сверка находит записи, которые не дошли. (Частичный успех — это все равно сбой, который нужно понять)
За пределами экзамена
Заголовок раздела «За пределами экзамена »Экзамен — это пол, а не потолок. Вот привычки из этой главы, которые нужны архитектору, независимо от того, спросят ли о них когда-нибудь на экзамене.
- Кто-то должен держать чертеж. Архитектура — это принятие хороших решений при неполной информации и понимание их последствий.
- Модель данных — это скелет. Все остальное строится на ней.
- Тест на обратимость: насколько трудно это отменить и сколько всего будет от этого зависеть?
- Архитектура создает гравитацию. Изменения делают дорогими зависимости, а не сами изменения.
- Думайте о радиусе поражения — внутри Salesforce и на уровне всего предприятия. Архитектура — это двустороннее движение.
- Запишите почему: контекст, варианты, решение, последствия, владелец, пересмотр. Заменяйте новым, а не стирайте.
- Лучшее в чем? Неоптимальное решение может быть частью оптимальной архитектуры, если вы знаете, что принимаете его.
- Держите в голове картину оптимального, чтобы знать, в какую сторону вы от него удаляетесь и почему.
- Think Correct. Think Fast. Скорость дает обдумывание, сделанное заранее.
- Стройте для сегодняшнего дня. Планируйте на завтра. Планируйте на случай сбоя. И берите 30 % роста, когда никто не называет вам цифру.
- Учите девять вопросов, а не только ответы.
- ИИ — это ракетный ускоритель. Генерация — не суждение, необратимое по-прежнему необратимо, а проверка человеком — не формальность. Доверяй, но проверяй.
Ключевые термины
Заголовок раздела «Ключевые термины »| Термин | В одной строке |
|---|---|
| Архитектурное решение | Решение, которое трудно отменить и от которого многое зависит |
| Тест на обратимость (Reversibility Test) | Насколько трудно это отменить и сколько всего будет от этого зависеть? |
| Гравитация | Зависимости, которые со временем собираются вокруг решения |
| Радиус поражения (blast radius) | Все остальное, что сдвигается, когда меняется решение |
| Запись о решении | Контекст, варианты, решение, последствия, владелец и точка пересмотра — коротко |
| Компромисс | Что вариант дает и чем жертвует, чтобы это получить |
| Подразумеваемое требование | То, чего бизнес ожидает без просьб, например восстановления после сбоя загрузки |
| «Число нулей» Steve (Steve’s Number of Zeros) | Еще один ноль в объеме может изменить всю архитектуру |
| Сверка | Сравнение того, что должно было произойти, с тем, что произошло, запись за записью |
| Вывод из употребления | Пометить что-то как уходящее, а затем обдуманно вывести, вместо того чтобы менять на месте |
| Пользователь с большим объемом (high-volume user) | Пользователь сообщества (среди лицензий — Customer Community) без роли, вне модели общего доступа |
| Разрастание схемы | Объекты и поля, которые накапливаются, потому что их дешево создавать, пока модель не оказывается никем не спроектированной |
Проверьте себя
Заголовок раздела «Проверьте себя »Короткие сценарии в стиле курса. Определитесь с ответом, прежде чем его открыть.
1. Команда продаж просит добавить в возможность (Opportunity) поля «Согласующий 2» и «Согласующий 3», каждое с датой. Что вы спросите и что, возможно, построите?
Спросите почему и сколько может быть согласований. Если их может быть больше двух-трех, требование — отслеживать каждое согласование, а не добавлять поля: дочерний объект, по одной записи на согласование. Перечитайте Не принимайте требование на веру.
2. Один человек хочет переименовать метку поля, а другой — изменить формат идентификатора клиента, который уже хранят пять систем. Что заслуживает больше вашего внимания и почему?
Идентификатор. Метку изменить дешево. Идентификатор не проходит тест на обратимость: его трудно отменить, и от него уже многое зависит. Тратьте внимание соразмерно цене ошибки. Перечитайте Некоторые решения дешево изменить.
3. Текстовое поле используется уже много лет. Теперь бизнес хочет хранить в нем число. Как вы поступите?
Не меняйте его на месте. Выясните, что от него зависит (Flows, Apex, отчеты, интеграции, агенты) и что будет со старыми данными. Обычно: добавить новое поле, обдуманно провести миграцию и вывести старое из употребления. Перечитайте Осторожнее с изменением скелета.
4. 1 200 точек, 100 записей на прием на точку в день, около 305 дней в году, две записи на каждый прием, хранение пять лет, рост 30 %. Примерно сколько получится записей и почему это важно?
Около 73 млн записей за первый год (36,6 млн записей на прием, по две записи на каждую) и более 650 млн за пять лет с учетом роста. Та же функция, пара лишних нулей — и совсем другая архитектура. Перечитайте Знайте свои цифры.
5. Ночная загрузка сообщает «завершено» по миллиону записей. Как узнать, что все сработало?
Провести сверку. Принимающая сторона подтверждает каждую сохраненную запись; отправитель сравнивает то, что отправил, с тем, что подтверждено. Недостающие подтверждения означают, что не сработало, что бы ни говорил статус задания, и показывают, какие записи повторить, передать человеку или по каким поднять тревогу. Перечитайте Частичный успех — это все равно сбой, который нужно понять.
6. Сообществу из 15 млн пользователей Customer Community нужен сложный доступ к записям. Кто-то предлагает Apex sharing. В чем проблема?
Это пользователи с большим объемом: без ролей, вне модели общего доступа, так что нет записи общего доступа, которую мог бы записать Apex. Доступ определяется наборами общего доступа и группами общего доступа. Какие инструменты общего доступа вообще существуют, определила лицензия. Перечитайте Разобранный пример: Apex sharing.
7. ИИ-инструмент за минуты генерирует двадцать объектов для нового приложения. В чем теперь работа архитектора?
Решить, не должно ли их быть пять. Понять модель достаточно хорошо, чтобы ее защитить: почему эти объекты и связи, где ключи и мастер-данные, что будет в масштабе. Проверить факты, на которые он опирался. Генерация — не суждение. Перечитайте Дешевая реализация смещает ценность.
Дополнительно
Заголовок раздела «Дополнительно »- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (на английском, проверено 2026-09-25): официальный список целей и их веса. Всегда проверяйте актуальную версию, прежде чем записываться на экзамен.