Спроектируйте физическую модель Salesforce

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

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

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

Модуль 10 из 10 главы Архитектура данных Salesforce, глава 3 курса Data Architect. Каждый модуль самостоятелен. Назад: Поддержание согласованности данных · Далее: учебное пособие к главе, а затем следующая глава, Понимание корпоративных данных

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

Вся эта глава была одним длинным доводом в пользу того, что у платформы есть форма: стандартные и пользовательские объекты, места, где могут жить данные, типы полей, связи, владение, лицензии, правила согласованности, хранение и масштаб. Каждый из этих элементов может изменить то, как будет построена логическая модель из главы 2. Теперь соберем все вместе на одном срезе Steve Trucking.

Один срез, а не вся компания. Ошибка, которую я вижу у архитекторов, — попытка решить все предприятие на одной диаграмме. Мне нужно то, о чем можно рассуждать: розничный партнер присылает манифест, Steve Trucking доставляет то, что в нем указано, а мы храним то, что нам нужно о каждой доставке. Затем принимаем физические решения по одному. Полный проект — это контрольная точка части 1.

Начнем с того, что мы уже знаем

Концептуальную работу проделала глава 2: розничный партнер (Retail Partner), получатель (Recipient), манифест (Manifest), доставка (Delivery), позиция доставки (Delivery Item), вид остановки, бригада (Crew), грузовик (Truck), распределительный центр (DC), фотографии. Мы назвали связи и спросили, что они означают. Повторять это я не буду. Теперь вопрос в том, как эти понятия живут в Salesforce. Один факт из брифа важен сразу: в Steve Trucking уже работает Field Service для встреч, бригад и мобильного приложения.

Розничный партнер: не изобретайте организацию заново

Розничный партнер — это компания, на которую работает Steve Trucking. В Salesforce уже есть объект, созданный для компаний: организация (Account). Чистое соответствие. Поэтому никакого Retail_Partner__c только потому, что бизнес говорит «партнер». Это организация с типом записи «Розничный партнер», чтобы отличать ее от других организаций, и вместе с ней приходят договоры, обращения, контакты для руководителей распределительных центров и доступ к порталу для этих контактов. Простое решение. Не все такие.

Номер заказа партнера — не наш идентификатор

Каждый розничный партнер присылает собственные номера. Заказ одного партнера выглядит как 8843119, другого — как A-984732. Эти номера важны, но чьи они? Партнера. У Salesforce есть свой ID записи, а у партнера — номер, которым он пользуется, когда говорит с нами. Могут существовать оба; это «одна вещь, несколько идентификаторов» из главы 2.

Поэтому номер партнера становится External ID, по которому интеграция сопоставляет обновления. А поскольку два партнера могут использовать один и тот же номер, уникальный ключ — это партнер плюс номер, а не один номер. Не делайте номер партнера универсальным идентификатором доставки только потому, что он пришел первым, и не заставляйте интеграцию искать по текстовому полю каждый раз, когда ей нужно найти запись.

Доставка: смотрите на корабль-носитель

Вот здесь возникает соблазн создать Delivery__c. Бизнес сказал «доставка», значит, нам нужен объект Delivery. Именно этого я не хочу, чтобы вы делали первым делом. Смотрите на корабль-носитель, как мы делали в модуле 2. Что уже есть в Salesforce для работы, выполняемой на месте, с жизненным циклом, позициями, планированием и бригадой в поле? Рабочий заказ (Work Order) из Field Service: Salesforce описывает его как работу выездного обслуживания, которую нужно выполнить для клиента (WorkOrder (opens in a new tab)). Запланированный визит и его временное окно — это сервисная встреча (Service Appointment), и именно ее планирует диспетчерская и показывает приложение бригады.

Итак, доставка → рабочий заказ. Не потому, что совпадают слова: они не совпадают. А потому, что поведение совпадает с возможностью платформы, за которую мы уже платим и которой собираемся пользоваться. Стандартному объекту не обязательно разделять словарь бизнеса. Он должен правильно представлять понятие.

Click to enlarge

Шаг 1 из 4: корабль-носитель. Каждая карточка — это бизнес-понятие, а под ним его объект Salesforce.

Но стандартные объекты приходят с багажом

Вторая половина: рабочий заказ не бесплатен. Он приносит лицензирование Field Service, собственные связи, поведение безопасности, обязательные поля, автоматизацию и жизненный цикл, а другие части платформы ожидают, что он будет вести себя определенным образом. Мы выбираем его, потому что соответствие чистое и мы используем то, что построено вокруг него. Если бы Steve Trucking не нужен был Field Service вообще и модель на каждом шагу боролась с процессом, я бы пересмотрел решение. Архитектура — это соответствие, а не название.

Позиции доставки: следуйте модели

Как только доставка стала рабочим заказом, посмотрите на остальную часть этой модели, прежде чем что-то изобретать. Позиция рабочего заказа (Work Order Line Item) — это подзадача рабочего заказа (WorkOrderLineItem (opens in a new tab)): холодильник, установка, вывоз старой техники. Итак, позиция доставки → позиция рабочего заказа. Обратите внимание: первое решение сформировало второе. Мы не выбираем объект для каждой сущности по отдельности. Примите модель и поймите остальную ее часть, прежде чем строить вокруг нее собственные структуры.

Что это за остановка?

В Steve Trucking остановка бывает только доставкой, доставкой с установкой или доставкой с вывозом, и у каждого вида своя продолжительность, свои навыки бригады и свой чек-лист установки. В главе 2 мы решили, что это сущность, а не метка. В Field Service она уже есть: тип работы (Work Type), шаблон для типа работы, который можно применять к рабочим заказам и их позициям (WorkType (opens in a new tab)). Итак, вид остановки → тип работы. Опять же, не потому, что существует что-то под названием Work Type, а потому, что совпадают понятие и поведение.

Click to enlarge

Шаг 2 из 4: следуйте модели. Позиции и тип работы приходят вместе с рабочим заказом.

Манифест: вот теперь мне нужен пользовательский объект

Есть ли стандартный объект для «списка партнера на вторник для DC в Финиксе»? Не совсем, и я не стану втискивать его в посторонний объект только ради того, чтобы сказать, что мы остались на стандартных. Манифест → Manifest__c. Это единица приема: откуда он пришел (файл, пакет через API), когда, его статус и итоги, а когда партнер присылает его повторно в тот же день, — что сравнивается. Каждая строка манифеста становится рабочим заказом, связанным с ним.

Пользовательский объект — это не провал. Это то, что дает нам платформа, когда у понятия нет чистого стандартного дома. Ошибка не в том, чтобы создать пользовательский объект, а в том, чтобы создать его, не проверив, есть ли это понятие на платформе.

Click to enlarge

Шаг 3 из 4: единственный пользовательский объект — там, где не подходит ни один стандартный.

Фотографии: то, что Salesforce может их хранить, не значит, что должен

«Нам нужны фотографии доставок в Salesforce». Что значит «в Salesforce»? Пользователям нужно их видеть из Salesforce, да. Значит ли это, что файлы изображений должны жить в хранилище ядра? Не обязательно. Посчитайте нули: около четырех фотографий на доставку, больше при установке, при миллионе доставок в год — это четыре-пять миллионов фотографий в год, а количество доставок растет на 30 % в год.

Поэтому моя исходная позиция: не превращайте org ядра в гигантский фотоархив только потому, что пользователям нужен доступ к фотографиям. Файлам место в хранилище, построенном для такого объема, вне ядра, а Salesforce хранит то, что нужно, чтобы их найти и показать: ссылку, количество или небольшую индексную запись на каждую фотографию и флаг о том, что обязательные фотографии установки собраны. Доступ к данным и место, где данные физически живут, — два разных вопроса. Это возвращается модуль 4.

Поля: сделайте смысл видимым

Рабочему заказу нужны поля: номер партнера, окно доставки, фактическое время доставки, статус, заметки вроде «код ворот» или «во дворе собака». Я не буду превращать это в каталог полей; это сделал модуль 6. Пройдите по вопросам для каждого: что оно означает, кто им владеет, меняется ли оно, идентификатор ли это, контролируемый словарь, хранится оно или вычисляется, чувствительно ли оно. Номер партнера — это External ID, поэтому его уникальность — часть контракта интеграции, а не просто флажок. Фактическое время доставки — это момент, значит, Date/Time. Статус управляет поведением, значит, контролируемый список и никогда не свободный текст. А заметки о доставке, касающиеся чьего-то дома, — это персональные данные, поэтому их классифицируют. Каждое поле прослеживается до смысла.

Связи: не просто соединяйте прямоугольники

Организация с рабочим заказом, рабочий заказ с его позициями, манифест с рабочим заказом, тип работы, описывающий остановку. Затем для каждой линии — вопросы из модуля 7: может ли дочерняя запись существовать сама по себе, кто ею владеет, наследуется ли доступ, может ли она переместиться, что происходит при удалении, сколько дочерних записей может накопиться? Все рабочие заказы под горсткой организаций розничных партнеров — это сотни тысяч дочерних записей на одного родителя: вопрос перекоса, на который мы ответим в части 2. А для стандартных связей Field Service проверьте, как Salesforce их уже построил, вместо того чтобы считать, что они совпадают с тем, что спроектировали бы мы. Принимая стандартную модель, вы принимаете и решения, которые Salesforce принял внутри нее. Поймите их, прежде чем строить поверх.

Владение и получатель: не позволяйте решать значению по умолчанию

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

Кто владеет доставкой? Мы ответили на это в модуле 8, и ответ напрямую переносится на рабочий заказ: здесь владение не определяет ничей доступ, поэтому интеграционный пользователь владеет рабочими заказами, которые создает. Диспетчеры видят заказы своего распределительного центра, бригады — своих маршрутов, а каждый розничный партнер видит свои через портал, и все это через общий доступ, а не через владение. У интеграционного пользователя нет роли, и он не входит в публичные группы, которые используют наши правила общего доступа, потому что при 3 300 в день он переходит порог 10 000 записей за три дня. И мы записываем, что произойдет, если этого пользователя когда-нибудь заменят.

Что такое получатель? Контакт? Персональная учетная запись (Person Account)? Что-то, что хранится только в доставке? Это зависит от того, есть ли у Steve Trucking вообще отношения с этими людьми (они клиенты розничных партнеров), может ли один партнер когда-либо видеть получателей другого, как долго можно хранить их персональные данные, и от масштаба: около миллиона новых получателей в год. Всего этого у нас пока нет, и это нормально. Иногда правильный ответ — мы пока знаем недостаточно. Запишите вопрос и идите за информацией; не прячьте неопределенность в пользовательском объекте. Мы ответим на него на контрольной точке части 1, после того как главы 4–6 дадут нам картину предприятия и мастер-данных.

Согласованность: защищайте модель на правильном уровне

Лестница из модуля 9 применима и здесь: номер партнера — это External ID, уникальный, поэтому повторно присланный манифест выполняет upsert, а не создает дубликаты; статус — ограниченный список; фактическое время доставки обязательно только тогда, когда статус говорит «Доставлено»; остановку с установкой нельзя закрыть без чек-листа и фотографий. Не один гигантский flow. Каждое правило на своей ступени.

Где живет каждая часть

Еще один проход по срезу с вопросом из модуля 4: где живет каждая часть данных? В моей учебной презентации это один слайд, логическое против физического: логические сущности из главы 2 и то, куда каждая из них физически попадает: в ядро — как sObject (__c, если он пользовательский) или big object (__b), или вне ядра — как внешний объект (__x) или данные, которые вообще никогда не попадают в Salesforce.

• В ядре, в ежедневной работе: организация, рабочие заказы и их позиции, сервисные встречи, типы работ, Manifest__c.
• В ядре, в архиве: доставки старше трех лет переходят в Delivery History, big object; они все еще там для претензий — в сарае.
• По ссылке: собственные данные заказа розничного партнера остаются в системе партнера; мы храним номер партнера как External ID и добираемся до остального через внешний объект или интеграцию, когда это кому-то нужно.
• Вне ядра: фотографии — в хранилище, построенном для миллионов изображений, со ссылкой из рабочего заказа.

Это и есть физическая модель: не только какой объект, но и какой дом.

Теперь посмотрите на весь срез

• Розничный партнер → организация (Account) с типом записи «Розничный партнер»; руководители DC — контакты.
• Доставка → рабочий заказ Field Service, запланированный через сервисную встречу.
• Позиция доставки → позиция рабочего заказа.
• Вид остановки → тип работы.
• Манифест → пользовательский Manifest__c.
• Номер партнера → External ID на рабочем заказе, уникальный в пределах партнера.
• Фотографии → хранятся вне ядра; Salesforce хранит ссылку и флаг полноты.
• История доставок → через три года архивируется в big object.
• Владение → интеграционный пользователь, а доступ — через общий доступ (модуль 8).
• Получатель → открытый вопрос для контрольной точки части 1.

Click to enlarge

Шаг 4 из 4: весь срез — в ядре, в архиве и вне ядра. Каждая линия — lookup: Salesforce построил Field Service на связях lookup, и мы принимаем его решения вместе с ним.

Диаграмма — это не архитектура

Я могу вручить вам эту диаграмму, и этого недостаточно. Архитектура — это рассуждение, которое за ней стоит. Почему организация? Компания с чистым соответствием. Почему рабочий заказ, а не Delivery__c? Доставка ведет себя как выездная работа, а Field Service уже на месте. Почему пользовательский манифест? Нет чистого стандартного дома. Почему фотографии — не просто Files? Объем и экономика хранения. Почему External ID? Другой системе нужен стабильный идентификатор через границу систем. Почему рабочими заказами владеет интеграционный пользователь? Здесь владение не определяет доступ, и так журнал аудита остается честным. Почему получатель все еще открытый вопрос? Мы еще не ответили на достаточное число вопросов. Линии — это результат; их породили решения.

Так что вот привычка, с которой я хочу, чтобы вы ушли из главы 3. Укажите на что угодно в физической модели и спросите почему? Почему этот объект, этот тип, эта связь, этот владелец, это место, это правило? Вы должны суметь проследить ответ назад: от конфигурации к физической модели, к логической модели, к бизнес-требованию. Если не можете, значит, кто-то проектировал из Setup.

И вы наверняка заметили цифры, которые мы до конца не проработали: доставки на партнера, позиции, фотографии, хранение, архивирование. Хорошо. Спрашивайте про число нулей, прежде чем закрепить проект: модель, которая прекрасно работает на пятидесяти тысячах записей, может вести себя совсем иначе на пятистах миллионах. Это часть 2.

За пределами экзамена: что меняет ИИ. Дайте ИИ бриф Steve Trucking, и он за секунды выдаст схему: Account, Work Order, пользовательские объекты, поля, даже метаданные для развертывания. Это фантастический ускоритель, но это не ревью. Работа архитектора смещается к проверке сопоставлений и их последствий: соответствие, лицензии, владение, жизненный цикл, масштаб, идентификаторы, безопасность и то, что остается вне платформы. ИИ — это ракетный ускоритель; он не скажет вам, туда ли вы направлены.

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

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

В начале этой главы мы спросили, как модель должна жить в Salesforce. Это и есть архитектура данных Salesforce: не создание объектов, не заучивание Setup, не рисование прямоугольников покрасивее, а осознанная подгонка бизнес-модели к форме платформы. Каждая структура — это обязательство. Принимайте те, которые можете объяснить.

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

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) и WorkType (opens in a new tab), на английском, проверено 2026-10-02.
• Бриф Steve Trucking.