Steve Trucking, як я б це спроєктував
Також доступно 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 з 6 розділу Основні дані та ідентичність, розділ 6 курсу Data Architect, і кінець Частини 1. Попередній: Коли авторитетність спільна · Наступний: Частина 2 починається з розділу Проєктування для масштабу (coming soon)
Питання, на яке відповідає ця контрольна точка: Чи можете ви зібрати Частину 1 разом на справжньому сценарії?
Спершу спробуйте завдання. Це мій розбір завдання Контрольної точки 1. Якщо ви ще не намалювали власного дизайну, зробіть це, перш ніж читати далі. Цінність у порівнянні ваших міркувань із моїми, а не в читанні відповіді.
Це «як я б це спроєктував»: можливе життєздатне рішення, а не та сама відповідь, із названими компромісами і зайнятими позиціями. Ми ще не розглядали великих обсягів даних, дизайну запитів, інтеграційних шаблонів, міграції чи транзакцій, і це навмисно: архітектура розвивається, коли ви дізнаєтеся більше. Але Частина 1 дає достатньо, щоб поставити скелет.
Почніть із чисел
Section titled “Почніть із чисел ”З брифу: близько 3 300 доставок на робочий день, мільйон на рік, зростання 30% на рік. Близько 1,6 позиції на доставку (1,6 мільйона на рік); близько восьми змін статусу на доставку (8 мільйонів на рік); чотири-п’ять мільйонів фото на рік; близько 200 000 показань GPS на день; близько 180 000 звернень на рік; три роздрібні партнери, що надсилають маніфести трьома різними способами; дев’ять розподільчих центрів; 330 вантажівок із бригадами з двох людей. І Steve Trucking уже має одну org Salesforce із Service Cloud, Field Service і порталом партнерів. Порахуйте нулі, перш ніж малювати хоч один прямокутник. Нижче вони вирішать кілька речей.
Ядро доставок: дивіться на материнський корабель
Section titled “Ядро доставок: дивіться на материнський корабель ”Доставки — серце всього, і Field Service уже займається диспетчеризацією. Тож я починаю зі стандартної моделі Field Service, як це зробив зріз у розділі 3:
| Бізнес-поняття | Об’єкт Salesforce | Чому |
|---|---|---|
| Роздрібний партнер | Account (тип запису Retail Partner) | Компанія, з якою Steve Trucking має договір; несе договори, звернення й доступ до порталу |
| Персонал партнера (менеджери DC, працівники магазинів) | Contact | Користувачі порталу мають бути Contacts |
| Одна доставка: один отримувач, одна адреса, одне замовлення партнера, один день | Робоче замовлення (Work Order) | Одиниця роботи Field Service; на ній висять планування, мобільний застосунок і сервісні звіти |
| Кожен предмет чи послуга: холодильник, встановлення, вивезення | Рядок робочого замовлення (Work Order Line Item) | Розділяє роботу, керує чек-листами й рахунками |
| Вид зупинки: лише доставка, зі встановленням, з вивезенням | Тип робіт (Work Type) | Встановлює тривалість, навички і чек-лист встановлення |
| Запланований візит і його вікно | Сервісний візит (Service Appointment) | Те, що планує Field Service і показує застосунок бригади |
| Бригади й вантажівки; зони диспетчеризації DC | Service Resource, Service Crew, Service Territory | Field Service планує бригаду як один ресурс |
| Запити отримувачів, претензії партнерів | Case | Сервісна консоль, entitlements, email-to-case |
| Перелік партнера на вівторок для DC у Фініксі | Manifest__c (користувацький) | Нічого стандартного не представляє одиницю отримання, звірки й повторного відтворення |
Усе інше лишається стандартним. Опір іще більшій кількості користувацьких об’єктів — свідомий: запитання розділу 1 було, коли архітекторові варто опиратися ще одному, і тут відповідь — «майже завжди». Рядок замовлення партнера, наприклад, — не новий об’єкт. Це робоче замовлення, ідентифіковане номером партнера.
Вона виростає з фіналу розділу 3 (Спроєктуйте фізичну модель Salesforce): ті самі об’єкти на тих самих місцях, а до них додано бригаду, зону диспетчеризації, звернення і те, що Контрольна точка 1 тримає поза ядром.
Ключ, що зіставляє замовлення партнера з доставкою
Section titled “Ключ, що зіставляє замовлення партнера з доставкою ”Кожен рядок маніфесту стає одним робочим замовленням, пов’язаним зі своїм маніфестом. Ключ — запитання, на яке я найбільше хочу відповіді: як ми знаємо, що цей рядок від партнера — це та доставка? Моя відповідь: External ID на робочому замовленні, складений із роздрібного партнера і власного номера замовлення й доставки партнера (щось на кшталт KEYSTONE-PHX-8843119-1), позначений як унікальний. Одне поле на джерело, один до одного. Це ідентифікатор партнера, а не наш: «кілька ідентифікаторів для однієї речі» з розділу 2 і «партнер володіє своїм номером замовлення» з модуля 1.
Чому це важливо: маніфести приходять за день-два наперед і переглядаються в день доставки. З цим ключем кожен повторно надісланий чи переглянутий маніфест робить upsert, а не створює дублікати. Перегляд оновлює робоче замовлення, поле його фіксує, а зміна вже маршрутизованої доставки сповіщає координатора: зміну партнера застосовано, але позначено, доки диспетчеризація її не підтвердить. Саме це й змінюється порівняно з малюнком із розділу 4. Сьогодні кожен маніфест потрапляє в RouteDesk, а координатори вручну переносять маршрути в Salesforce, а завершені зупинки — назад. У цьому дизайні маніфести приходять просто в Salesforce через upsert за ключем партнера; RouteDesk виводять з ужитку, і ручне перенесення припиняється. Розділ про інтеграцію проєктує три вхідні формати. Рішення щодо даних — це ключ.
Отримувач: персональний акаунт, Contact чи ні те, ні інше?
Section titled “Отримувач: персональний акаунт, Contact чи ні те, ні інше? ”Це найцікавіше рішення щодо даних у Частині 1, тож ось варіанти, а потім мій вибір.
Варіант A: персональні акаунти. Кожен отримувач стає персональним акаунтом, пов’язаним із кожною доставкою. За: стандартно, природно працює із Service Cloud, повідомленнями й консоллю, впізнає повторних отримувачів. Проти: близько мільйона нових отримувачів на рік, кожен — персональний акаунт, що займає приблизно вдвічі більше сховища, ніж бізнес-акаунт (Estimated Record Size by Object Type (opens in a new tab)), тож за два роки — один із найбільших об’єктів в org. І отримувачі — не клієнти Steve Trucking. Вони клієнти кожного роздрібного партнера, а Steve Trucking ніколи не має змішувати клієнта одного партнера з клієнтом іншого (S2).
Варіант B: Contacts під акаунтом роздрібного партнера. Проти: мільйон Contacts під трьома-чотирма акаунтами — це перекіс «батько — дочірній» у величезному масштабі, далеко за настановою Salesforce приблизно в 10 000 дочірніх записів на батька (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). Цей варіант треба показати — і відкинути.
Варіант C: отримувач живе на доставці. Ім’я, телефон, пошта, адреса й нотатки до доставки отримувача — поля на робочому замовленні (поля адреси там уже стандартні), взяті з маніфесту. За: жодного нового великого об’єкта; дані живуть рівно стільки, скільки вони потрібні доставці; видалення відбувається для кожної доставки за графіком партнера; а ізоляція партнерів дістається безкоштовно, бо кожна доставка належить одному партнерові. Проти: повторного отримувача не впізнають як ту саму людину.
Ось баланс, якого треба досягти. Чи колись виникне потреба впізнати кілька доставок як ту саму людину за тією самою адресою? Дати цій людині вхід у систему? Це межа між отримувачем, якому потрібен власний запис, і даними отримувача, які є просто даними про доставку. І є середній шлях. Несіть власний ID клієнта роздрібного партнера як поле на доставці — Retail Partner Customer ID. Він не створює запису отримувача, але пов’язує доставки, які партнер надсилає для того самого клієнта, а це початок більш уніфікованого клієнтського досвіду, і він веде просто назад до системи роздрібного партнера, де цей клієнт насправді живе. Це їхній ідентифікатор, тож він має сенс лише разом із партнером: клієнт 4417 одного партнера не має нічого спільного з клієнтом 4417 іншого.
На мою професійну думку, варіант C — правильний вибір. Невпізнавання прийнятне, навіть бажане: Steve Trucking не має з цими людьми стосунків поза доставкою. Це знову модуль 1: отримувач — клієнт партнера, і партнер — авторитет щодо того, хто вони. І це розділ 5: персональні дані, що потрапляють в одне місце, прив’язані до однієї доставки, набагато легше захищати, зберігати й видаляти. І це витримує перевірку нормальними формами з розділу 2: дані отримувача один до одного з доставкою, тож їм місце на ній. Окремий дочірній запис отримувача заощадив би кілька повторюваних значень ціною ще одного об’єкта, ще одного зв’язку та їхніх накладних витрат, а заощадити більше він міг би, лише якби ми вважали ту саму людину однією між роздрібними партнерами, чого ми робити не будемо. Тож доставка несе отримувача, а Retail Partner Customer ID — шлях назад до власної системи партнера.
Чи уніфікував би я отримувачів між партнерами?
Section titled “Чи уніфікував би я отримувачів між партнерами? ”John Smith, 123 Main Street, з’являється в маніфесті Redrock і в маніфесті Brightwave. Мабуть, та сама людина. Чи має Steve Trucking їх уніфікувати? Ні, свідомо ні. Уніфікація отримувачів між роздрібними партнерами порушила б S2: партнер ніколи не має бачити отримувачів іншого партнера, а уніфікована ідентичність — саме той міст, через який усе витікає. Це позиція цього розділу на практиці: зіставляйте менше там, де змішування дороге, а тут змішування дуже дороге.
Якщо роздрібний партнер згодом захоче впізнавати повторних отримувачів у межах власних доставок, це робота для інструмента розпізнавання ідентичності, як-от у Data 360, з обмеженням цим партнером: карта в стилі registry, а не персональний акаунт, і ніколи між партнерами. Карта того, хто є хто, не дає власності і не дає доступу.
Що лишається в org, а що ні
Section titled “Що лишається в org, а що ні ”Розділ 3 питав, де мають жити дані. Тут на це відповідають нулі:
- Поточний статус живе на сервісному візиті й робочому замовленні. Історія змін статусу, близько 8 мільйонів на рік і більше, не мусить жити в core org. Кожна зміна публікується як подія і зберігається у сховищі даних, Snowflake. Org тримає поточний стан; історія досі доступна для сервісу, операцій і аналітики, просто не в операційній базі даних.
- Фото (чотири-п’ять мільйонів на рік, деякі з людьми чи інтер’єром дому) живуть поза core у сховищі, збудованому для такого обсягу, і завантажуються просто із застосунку бригади. Org тримає лише потрібне: невеликий запис-індекс на кожне фото або лише лічильник і позначку «обов’язкові фото встановлення є». Я віддаю перевагу легшому варіанту: тримайте org худою, а сховище фото нехай володіє своїм індексом і зберіганням.
- Показання GPS (200 000 на день) лишаються у FleetLink і йдуть у Snowflake; org потрібна лише остання позиція для сторінки відстеження й карти диспетчера.
- Вісім років історії RouteDesk (близько 5 мільйонів доставок) ідуть у сховище даних чи архів, досяжні для претензій. Що, якщо взагалі щось, потрапить в org — рішення про міграцію для Частини 2.
Контрольна точка 1: що я б спроєктував. Ті самі місця, що й на ландшафті з розділу 4 (Ландшафт Steve Trucking), але без ручного перенесення і без таблиці.
Хто що бачить і кому потрібна ліцензія
Section titled “Хто що бачить і кому потрібна ліцензія ”- Роздрібні партнери бачать лише свої доставки (S2). Кожне робоче замовлення несе свого роздрібного партнера; користувачі порталу бачать доставки свого партнера, а менеджери DC — лише свого DC.
- Користувачам партнерів потрібна ліцензія порталу, що підтримує правила спільного доступу й ролі: Customer Community Plus чи Partner Community. Місця на стадіоні з розділу 3: найдешевші місця не отримують спільного доступу, потрібного цьому дизайну. Обидві ліцензії потребують ролей для зовнішніх користувачів, і Salesforce попереджає, що більше ролей уповільнює org (Experience Cloud User Licenses (opens in a new tab)). Роль на кожного партнера і кожен DC — нормально; роль на кожен магазин — ні.
Варто знати для іспиту. Знайте, які зовнішні ліцензії мають стандартний спільний доступ: Customer Community Plus і Partner Community (з ролями для зовнішніх користувачів), а не Customer Community, яка використовує sharing sets (набори спільного доступу).
- Отримувачам ліцензія не потрібна. Сторінка відстеження показує одну доставку через посилання з токеном, що має строк дії (S3), а не через вхід у систему.
- Стежте за перекосом. Сотні тисяч робочих замовлень на рік, що вказують на три-чотири акаунти партнерів, — це перекіс даних акаунтів. Один варіант — дочірній акаунт для кожного DC під кожним партнером, що розподіляє дочірні записи на дев’ять і більше частин; архівування завершених доставок після вікна претензій тримає кількість активних дочірніх на батька низькою. Частина 2 за це береться.
Чого я б не робив
Section titled “Чого я б не робив ”Я не створював би персональний акаунт для кожного отримувача лише тому, що отримувач — окрема людина. Я не вішав би мільйон Contacts на три акаунти. Я не будував би користувацький об’єкт Delivery поруч із робочим замовленням Field Service. Я не уніфікував би отримувачів між партнерами. Я не клав би мільйони фото чи показань GPS у сховище core. І я не називав би уніфікованого отримувача golden record, якщо ми насправді не ухвалили рішення про керування.
Що лишається відкритим
Section titled “Що лишається відкритим ”Частина 1 поставила скелет; Частина 2 його випробовує. Мірило LDV на третій рік (робочі замовлення, сервісні візити й рядки — усі на території великих обсягів за два-три роки), дизайн запитів для подань списків у межах партнера, три вхідні інтеграції й три потоки статусів, міграція з RouteDesk, транзакції в день доставки і дизайн безпеки за порталом. Steve Trucking теж зміниться. Збережіть цей дизайн; ви до нього повернетеся.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Які стандартні об’єкти несуть ядро (тут — Field Service) і які користувацькі об’єкти справді виправдані (тут — один).
- Ключ, що зіставляє рядок замовлення кожного партнера з доставкою, і чому він належить партнерові.
- Що таке отримувач, виходячи зі стосунків, які Steve Trucking справді з ним має.
- Чи уніфікувати ідентичності і де змішування надто дороге, щоб ризикувати.
- Що лишається в org, що живе поза core і від яких ліцензій залежить дизайн.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Бриф і завдання Steve Trucking (D1, D3, DC1).
- Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) і Experience Cloud User Licenses (opens in a new tab) (англійською, перевірено 2026-10-14).
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (англійською), як посилається розділ 3.