ออกแบบโมเดลเชิงกายภาพของ 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)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 10 จาก 10 ในบท สถาปัตยกรรมข้อมูล Salesforce บทที่ 3 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: รักษาข้อมูลให้สอดคล้องกัน · ถัดไป: คู่มือทบทวนประจำบท แล้วจึงบทถัดไป ทำความเข้าใจข้อมูลองค์กร

คำถามที่โมดูลนี้ตอบ: เราจะเปลี่ยนโมเดลเชิงตรรกะให้เป็นสถาปัตยกรรม Salesforce ได้อย่างไร?

บทนี้ทั้งบทเป็นการโต้แย้งยาวๆ ว่าแพลตฟอร์มมีรูปร่างของมัน: ออบเจกต์มาตรฐานและที่กำหนดเอง ที่ที่ข้อมูลอยู่ได้ ประเภทฟิลด์ ความสัมพันธ์ ความเป็นเจ้าของ ไลเซนส์ กฎความสอดคล้อง พื้นที่จัดเก็บ และขนาด แต่ละอย่างเปลี่ยนวิธีสร้างโมเดลเชิงตรรกะของบทที่ 2 ได้ ตอนนี้มาประกอบทั้งหมดบนส่วนหนึ่งของ Steve Trucking

ส่วนเดียว ไม่ใช่ทั้งบริษัท ความผิดพลาดที่ผมเห็นสถาปนิกทำคือพยายามแก้ทั้งองค์กรในไดอะแกรมเดียว ผมอยากได้สิ่งที่เราคิดตามได้: พันธมิตรค้าปลีกส่งใบรายการสินค้า Steve Trucking จัดส่งสิ่งที่อยู่ในนั้น และเราเก็บสิ่งที่ต้องการเกี่ยวกับการจัดส่งแต่ละครั้ง แล้วเราตัดสินใจเชิงกายภาพทีละข้อ การออกแบบเต็มรูปแบบคือจุดตรวจสอบของส่วนที่ 1

เริ่มจากสิ่งที่เรารู้อยู่แล้ว

บทที่ 2 ทำงานเชิงแนวคิดไปแล้ว: พันธมิตรค้าปลีก ผู้รับ ใบรายการสินค้า การจัดส่ง รายการจัดส่ง ประเภทของจุดแวะ ทีมจัดส่ง รถบรรทุก ศูนย์กระจายสินค้า รูปถ่าย เราตั้งชื่อความสัมพันธ์และถามว่ามันหมายถึงอะไร ผมจะไม่พูดซ้ำ คำถามตอนนี้คือแนวคิดเหล่านั้นอยู่บน Salesforce อย่างไร ข้อเท็จจริงหนึ่งจากบรีฟสำคัญทันที: Steve Trucking ใช้ Field Service อยู่แล้วสำหรับนัดหมาย ทีมจัดส่ง และแอปมือถือ

พันธมิตรค้าปลีก: อย่าประดิษฐ์บัญชีขึ้นใหม่

พันธมิตรค้าปลีกคือบริษัทที่ Steve Trucking ทำงานให้ Salesforce มีออบเจกต์ที่ออกแบบมาสำหรับบริษัทอยู่แล้ว: Account (บัญชี) เข้ากันพอดี ดังนั้นไม่มี Retail_Partner__c เพียงเพราะธุรกิจพูดว่า “พันธมิตร” มันคือบัญชี มีประเภทเรกคอร์ด Retail Partner เพื่อแยกจากองค์กรอื่น และพร้อมกับมันคือสัญญา เคส ผู้ติดต่อสำหรับผู้จัดการ DC และการเข้าถึงพอร์ทัลสำหรับผู้ติดต่อเหล่านั้น การตัดสินใจง่าย ไม่ใช่ทุกข้อจะง่ายแบบนี้

หมายเลขคำสั่งซื้อของพันธมิตรไม่ใช่ตัวตนของเรา

พันธมิตรค้าปลีกแต่ละรายส่งหมายเลขอ้างอิงของตัวเอง คำสั่งซื้อของรายหนึ่งหน้าตาแบบ 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 หลักให้เป็นคลังรูปถ่ายยักษ์เพียงเพราะผู้ใช้ต้องเข้าถึงรูป ไฟล์ควรอยู่ในพื้นที่จัดเก็บที่สร้างมาสำหรับปริมาณขนาดนั้น นอก core โดย Salesforce เก็บสิ่งที่ต้องใช้เพื่อค้นหาและแสดงมัน: การอ้างอิง จำนวน หรือเรกคอร์ดดัชนีเล็กๆ ต่อรูป และแฟล็กว่ารูปติดตั้งที่กำหนดครบแล้ว การเข้าถึงข้อมูลกับที่ที่ข้อมูลอยู่จริงเป็นสองคำถามที่ต่างกัน นั่นคือโมดูลที่ 4 กลับมาอีกครั้ง

ฟิลด์: ทำให้ความหมายมองเห็นได้

ใบสั่งงานต้องมีฟิลด์: หมายเลขอ้างอิงของพันธมิตร ช่วงเวลาจัดส่ง เวลาจัดส่งจริง สถานะ หมายเหตุอย่าง “รหัสประตู” หรือ “มีสุนัขในสนาม” ผมจะไม่ทำให้นี่เป็นแคตตาล็อกฟิลด์ โมดูลที่ 6 ทำไปแล้ว ใช้คำถามกับแต่ละฟิลด์: มันหมายถึงอะไร ใครเป็นเจ้าของ มันเปลี่ยนไหม เป็นตัวระบุไหม เป็นคำศัพท์ที่ควบคุม เก็บไว้หรือคำนวณ เป็นข้อมูลอ่อนไหวไหม หมายเลขอ้างอิงของพันธมิตรคือ External ID ดังนั้นความไม่ซ้ำของมันเป็นส่วนหนึ่งของสัญญาการผสานรวม ไม่ใช่แค่ช่องติ๊ก เวลาจัดส่งจริงคือช่วงขณะหนึ่ง จึงเป็น Date/Time สถานะขับเคลื่อนพฤติกรรม จึงเป็นรายการที่ควบคุม ไม่ใช่ข้อความอิสระ และหมายเหตุการจัดส่งเกี่ยวกับบ้านของใครสักคนคือข้อมูลส่วนบุคคล จึงต้องถูกจัดประเภท ทุกฟิลด์สืบกลับไปหาความหมายได้

ความสัมพันธ์: อย่าแค่ลากเส้นต่อกล่อง

บัญชีกับใบสั่งงาน ใบสั่งงานกับรายการของมัน ใบรายการสินค้ากับใบสั่งงาน ประเภทงานที่อธิบายจุดแวะ แล้วใช้คำถามของโมดูลที่ 7กับแต่ละเส้น: ลูกอยู่ลำพังได้ไหม ใครเป็นเจ้าของ การเข้าถึงสืบทอดไหม ย้ายได้ไหม จะเกิดอะไรขึ้นเมื่อลบ ลูกจะกองทับกันได้มากแค่ไหน? ใบสั่งงานทุกใบภายใต้บัญชีพันธมิตรค้าปลีกไม่กี่บัญชีหมายถึงลูกหลายแสนรายการต่อแม่: คำถามเรื่อง skew ที่เราจะตอบในส่วนที่ 2 และสำหรับความสัมพันธ์มาตรฐานของ Field Service ให้ตรวจดูว่า Salesforce สร้างมันไว้อย่างไรแล้ว แทนที่จะสมมติว่ามันตรงกับที่เราจะออกแบบเอง เมื่อคุณรับโมเดลมาตรฐานมาใช้ คุณรับการตัดสินใจที่ Salesforce ทำไว้ข้างในมาด้วย เข้าใจมันก่อนสร้างทับ

ความเป็นเจ้าของและผู้รับ: อย่าให้ค่าเริ่มต้นตัดสินใจ

การตัดสินใจสองข้อที่ค่าเริ่มต้นยินดีจะตัดสินแทนเรา

ใครเป็นเจ้าของการจัดส่ง? เราตอบเรื่องนี้แล้วในโมดูลที่ 8 และมันส่งต่อมาที่ใบสั่งงานได้ตรงๆ: ที่นี่ความเป็นเจ้าของไม่ได้ขับเคลื่อนการเข้าถึงของใคร ดังนั้นผู้ใช้การผสานรวมเป็นเจ้าของใบสั่งงานที่มันสร้าง ผู้จัดการเดินรถเห็นของศูนย์กระจายสินค้าตัวเอง ทีมจัดส่งเห็นของเส้นทางตัวเอง และพันธมิตรค้าปลีกแต่ละรายเห็นของตัวเองผ่านพอร์ทัล ทั้งหมดผ่านการแชร์ ไม่ใช่ความเป็นเจ้าของ ผู้ใช้การผสานรวมไม่มีบทบาทและอยู่นอกกลุ่มสาธารณะที่กฎการแชร์ของเราใช้ เพราะที่ 3,300 ต่อวัน มันจะเกิน 10,000 เรกคอร์ดในสามวัน และเราเขียนบันทึกไว้ว่าจะเกิดอะไรขึ้นถ้าผู้ใช้คนนั้นถูกแทนที่

ผู้รับคืออะไร? ผู้ติดต่อ? บัญชีบุคคล? หรืออะไรบางอย่างที่เก็บไว้บนการจัดส่งเท่านั้น? ขึ้นอยู่กับว่า Steve Trucking มีความสัมพันธ์กับคนเหล่านี้หรือไม่เลย (พวกเขาเป็นลูกค้าของพันธมิตรค้าปลีก) พันธมิตรรายหนึ่งอาจได้เห็นของอีกรายหรือไม่ ข้อมูลส่วนบุคคลของพวกเขาเก็บได้นานเท่าไร และขนาด: ผู้รับใหม่ราวหนึ่งล้านคนต่อปี เรายังไม่มีข้อมูลทั้งหมดนั้น และไม่เป็นไร บางครั้งคำตอบที่ถูกคือเรายังรู้ไม่พอ เขียนคำถามไว้แล้วไปหาข้อมูลมา อย่าฝังความไม่แน่นอนไว้ในออบเจกต์ที่กำหนดเอง เราจะตอบมันที่จุดตรวจสอบของส่วนที่ 1 หลังจากบทที่ 4 ถึง 6 ให้ภาพขององค์กรและข้อมูลหลักแก่เรา

ความสอดคล้อง: ปกป้องโมเดลในชั้นที่ถูกต้อง

บันไดของโมดูลที่ 9ใช้ได้: หมายเลขอ้างอิงของพันธมิตรเป็น External ID ไม่ซ้ำ ใบรายการสินค้าที่ส่งซ้ำจึง upsert แทนการสร้างซ้ำ สถานะเป็นรายการแบบจำกัดค่า เวลาจัดส่งจริงจำเป็นเฉพาะเมื่อสถานะเป็น Delivered จุดแวะติดตั้งปิดไม่ได้ถ้าไม่มีเช็กลิสต์และรูปถ่าย ไม่ใช่ flow ยักษ์ตัวเดียว แต่ละกฎอยู่บนขั้นของตัวเอง

ข้อมูลแต่ละชิ้นอยู่ที่ไหน

ไล่ดูส่วนนี้อีกรอบ ด้วยคำถามของโมดูลที่ 4: ข้อมูลแต่ละชิ้นอยู่ที่ไหน? ในสไลด์สอนของผม เรื่องนี้คือสไลด์เดียว เชิงตรรกะเทียบกับเชิงกายภาพ: เอนทิตีเชิงตรรกะจากบทที่ 2 และที่ที่แต่ละตัวไปอยู่จริงทางกายภาพ: บน core เป็น sObject (__c ถ้าเป็นแบบกำหนดเอง) หรือ big object (__b) หรือนอก core เป็นออบเจกต์ภายนอก (__x) หรือข้อมูลที่ไม่เคยเข้ามาใน Salesforce เลย

• บน core ใช้งานทุกวัน: บัญชี ใบสั่งงานและรายการในใบสั่งงาน นัดหมายบริการ ประเภทงาน Manifest__c
• บน core เก็บถาวร: การจัดส่งที่เก่ากว่าสามปีย้ายไปที่ Delivery History (ประวัติการจัดส่ง) ซึ่งเป็น big object ยังอยู่ตรงนั้นสำหรับการเคลม อยู่ในโรงเก็บของหลังบ้าน
• อ้างอิง: รายละเอียดคำสั่งซื้อของพันธมิตรค้าปลีกเองอยู่ในระบบของพันธมิตร เราเก็บหมายเลขอ้างอิงของพันธมิตรไว้เป็น External ID และเข้าถึงส่วนที่เหลือผ่านออบเจกต์ภายนอกหรือการผสานรวมเมื่อมีคนต้องใช้
• นอก core: รูปถ่าย อยู่ในพื้นที่จัดเก็บที่สร้างมาสำหรับรูปภาพหลายล้านรูป โดยมีลิงก์จากใบสั่งงาน

นั่นคือโมเดลเชิงกายภาพ: ไม่ใช่แค่ออบเจกต์ไหน แต่บ้านไหนด้วย

ทีนี้มองภาพรวมของส่วนนี้

• พันธมิตรค้าปลีก → บัญชี มีประเภทเรกคอร์ด Retail Partner ผู้จัดการ DC เป็นผู้ติดต่อ
• การจัดส่ง → ใบสั่งงานของ Field Service จัดตารางผ่านนัดหมายบริการ
• รายการจัดส่ง → รายการในใบสั่งงาน
• ประเภทของจุดแวะ → ประเภทงาน
• ใบรายการสินค้า → ออบเจกต์ที่กำหนดเอง Manifest__c
• หมายเลขอ้างอิงของพันธมิตร → External ID บนใบสั่งงาน ไม่ซ้ำต่อพันธมิตร
• รูปถ่าย → เก็บนอกระบบหลัก Salesforce เก็บการอ้างอิงและแฟล็กความครบถ้วน
• ประวัติการจัดส่ง → เก็บถาวรใน big object หลังสามปี
• ความเป็นเจ้าของ → ผู้ใช้การผสานรวม โดยเข้าถึงผ่านการแชร์ (โมดูลที่ 8)
• ผู้รับ → เปิดไว้ สำหรับจุดตรวจสอบของส่วนที่ 1

Click to enlarge

ขั้นที่ 4 จาก 4: ภาพรวมของส่วนนี้ ทั้งบน core เก็บถาวร และนอก core ทุกเส้นเป็น lookup: Salesforce สร้าง Field Service บน lookup และเรารับการตัดสินใจของมันมาด้วย

ไดอะแกรมไม่ใช่สถาปัตยกรรม

ผมยื่นไดอะแกรมนั้นให้คุณได้ และมันไม่พอ สถาปัตยกรรมคือเหตุผลเบื้องหลังมัน ทำไมเป็นบัญชี? บริษัทที่เข้ากันพอดี ทำไมเป็นใบสั่งงานไม่ใช่ Delivery__c? การจัดส่งทำงานเหมือนงานภาคสนาม และมี Field Service อยู่แล้ว ทำไมใบรายการสินค้าเป็นออบเจกต์ที่กำหนดเอง? ไม่มีบ้านมาตรฐานที่เหมาะ ทำไมรูปถ่ายไม่เป็นแค่ Files? ปริมาณและเศรษฐศาสตร์ของพื้นที่จัดเก็บ ทำไมต้องมี External ID? ระบบอื่นต้องการตัวตนที่คงที่ข้ามขอบเขต ทำไมผู้ใช้การผสานรวมเป็นเจ้าของใบสั่งงาน? ที่นี่ความเป็นเจ้าของไม่ได้ขับเคลื่อนการเข้าถึง และนั่นทำให้ร่องรอยการตรวจสอบซื่อตรง ทำไมผู้รับยังเปิดไว้? เรายังตอบคำถามได้ไม่พอ เส้นคือผลลัพธ์ การตัดสินใจคือสิ่งที่สร้างมัน

ดังนั้นนี่คือนิสัยที่ผมอยากให้คุณติดตัวออกจากบทที่ 3 ชี้ไปที่อะไรก็ได้ในโมเดลเชิงกายภาพแล้วถามว่า ทำไม? ทำไมออบเจกต์นี้ ประเภทนี้ ความสัมพันธ์นี้ เจ้าของคนนี้ ที่นี้ กฎนี้? คุณควรสืบคำตอบย้อนกลับได้: จากการตั้งค่า ไปสู่โมเดลเชิงกายภาพ ไปสู่โมเดลเชิงตรรกะ ไปสู่ความต้องการทางธุรกิจ ถ้าทำไม่ได้ แปลว่ามีคนออกแบบจาก Setup

และคุณคงสังเกตเห็นตัวเลขที่เรายังไม่ได้คิดให้ครบ: การจัดส่งต่อพันธมิตร รายการ รูปถ่าย การเก็บรักษา การเก็บถาวร ดีแล้ว ถามหาจำนวนเลขศูนย์ก่อนล็อกการออกแบบ: โมเดลที่ทำงานได้สวยงามที่ห้าหมื่นเรกคอร์ดอาจทำงานต่างไปมากที่ห้าร้อยล้าน นั่นคือส่วนที่ 2

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร ให้บรีฟ Steve Trucking กับ AI แล้วมันจะสร้างสคีมาในไม่กี่วินาที: บัญชี ใบสั่งงาน ออบเจกต์ที่กำหนดเอง ฟิลด์ แม้แต่เมทาดาทาสำหรับ deploy นั่นคือตัวเร่งที่ยอดเยี่ยม และมันไม่ใช่การรีวิว งานของสถาปนิกเปลี่ยนไปเป็นการตรวจการจับคู่และผลที่ตามมา: ความเข้ากัน ไลเซนส์ ความเป็นเจ้าของ วงจรชีวิต ขนาด ตัวตน ความปลอดภัย และสิ่งที่อยู่นอกแพลตฟอร์ม AI คือจรวดเสริมแรงขับ มันไม่ได้บอกคุณว่าคุณชี้ไปทางที่ถูกหรือเปล่า

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• แนวคิดทางธุรกิจแต่ละอย่างจับคู่กับ Salesforce อย่างไร: ออบเจกต์มาตรฐาน ออบเจกต์ที่กำหนดเอง หรือสิ่งที่อยู่นอกระบบหลัก
• ตัวระบุ ฟิลด์ และความสัมพันธ์ใดที่ implement ความหมายทางธุรกิจโดยไม่เปลี่ยนมันอย่างเงียบๆ
• พฤติกรรมของแพลตฟอร์มและไลเซนส์อะไรที่มาพร้อมโมเดลมาตรฐานที่คุณรับมาใช้
• การตัดสินใจเรื่องความเป็นเจ้าของ วงจรชีวิต ความสอดคล้อง พื้นที่จัดเก็บ และขนาดข้อใดที่ต้องทำก่อนการออกแบบจะสมบูรณ์
• คำถามใดที่ยังเปิดไว้อย่างชัดเจน แทนที่จะซ่อนอยู่หลังการเลือก implement ตามอำเภอใจ

ตอนต้นบทนี้เราถามว่าโมเดลควรอยู่บน 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