Thiết kế mô hình vật lý Salesforce
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 10 trong 10 của chương Kiến trúc dữ liệu Salesforce, chương 3 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Giữ dữ liệu nhất quán · Tiếp theo: hướng dẫn ôn tập của chương, rồi đến chương sau, Hiểu dữ liệu doanh nghiệp
Câu hỏi mô-đun này trả lời: Làm thế nào để biến mô hình logic của chúng ta thành một kiến trúc Salesforce?
Cả chương này là một lập luận dài rằng nền tảng có hình dáng của nó: đối tượng chuẩn và tùy chỉnh, những nơi dữ liệu có thể nằm, kiểu trường, quan hệ, quyền sở hữu, giấy phép, quy tắc nhất quán, lưu trữ và quy mô. Mỗi thứ đều có thể thay đổi cách mô hình logic của chương 2 được xây dựng. Giờ hãy ghép chúng lại trên một lát cắt của Steve Trucking.
Một lát cắt, không phải cả công ty. Một sai lầm tôi thấy các kiến trúc sư hay mắc là cố giải quyết toàn bộ doanh nghiệp trong một sơ đồ. Tôi muốn một thứ chúng ta có thể suy luận được: một Đối tác bán lẻ gửi một bảng kê hàng, Steve Trucking giao những gì có trên đó, và chúng ta giữ những gì cần về mỗi lần giao hàng. Rồi chúng ta đưa ra từng quyết định vật lý một. Thiết kế đầy đủ là điểm kiểm tra của Phần 1.
Bắt đầu từ những gì chúng ta đã biết
Phần tiêu đề “Bắt đầu từ những gì chúng ta đã biết ”Chương 2 đã làm phần khái niệm: Đối tác bán lẻ, Người nhận, Bảng kê hàng, Giao hàng, Mặt hàng giao, loại điểm dừng, Tổ giao hàng, Xe tải, Trung tâm phân phối, ảnh. Chúng ta đã đặt tên cho các quan hệ và hỏi chúng có nghĩa là gì. Tôi sẽ không lặp lại. Câu hỏi bây giờ là những khái niệm đó sống trên Salesforce như thế nào. Một sự thật trong bản mô tả quan trọng ngay lập tức: Steve Trucking đã chạy Field Service cho lịch hẹn, tổ giao hàng và ứng dụng di động.
Đối tác bán lẻ: đừng phát minh ra một Tài khoản
Phần tiêu đề “Đối tác bán lẻ: đừng phát minh ra một Tài khoản ”Một Đối tác bán lẻ là một công ty mà Steve Trucking làm việc cho. Salesforce đã có một đối tượng được thiết kế cho công ty: Tài khoản. Phù hợp trọn vẹn. Vậy không có Retail_Partner__c chỉ vì nghiệp vụ nói “đối tác”. Nó là một Tài khoản, với một loại bản ghi Retail Partner để phân biệt với các tổ chức khác, và đi kèm là hợp đồng, trường hợp, Liên hệ cho các quản lý DC, và quyền truy cập cổng thông tin cho các Liên hệ đó. Quyết định dễ. Không phải quyết định nào cũng vậy.
Mã đơn hàng của đối tác không phải danh tính của chúng ta
Phần tiêu đề “Mã đơn hàng của đối tác không phải danh tính của chúng ta ”Mỗi Đối tác bán lẻ gửi mã tham chiếu riêng. Đơn hàng của đối tác này trông như 8843119, của đối tác kia như A-984732. Những con số đó quan trọng, nhưng chúng là của ai? Của đối tác. Salesforce có ID bản ghi riêng, và đối tác có mã tham chiếu họ dùng khi nói chuyện với chúng ta. Cả hai đều có thể tồn tại; đó là “một thứ, nhiều mã định danh” của chương 2.
Vì vậy mã tham chiếu của đối tác trở thành một ID bên ngoài mà tích hợp dùng để khớp các bản cập nhật. Và vì hai đối tác có thể dùng cùng một số, danh tính là đối tác cộng với mã tham chiếu, không phải chỉ mã tham chiếu. Đừng biến mã của một đối tác thành danh tính chung của lần giao hàng chỉ vì nó đến trước, và đừng bắt tích hợp tìm kiếm một trường văn bản mỗi khi cần tìm một bản ghi.
Giao hàng: hãy nhìn về phi thuyền mẹ
Phần tiêu đề “Giao hàng: hãy nhìn về phi thuyền mẹ ”Đây là chỗ rất dễ bị cám dỗ tạo Delivery__c. Nghiệp vụ nói “giao hàng”, nên chúng ta cần một đối tượng Delivery. Đó chính là điều tôi không muốn bạn làm đầu tiên. Hãy nhìn về phi thuyền mẹ, như chúng ta đã làm ở mô-đun 2. Salesforce đã có gì cho công việc được thực hiện tại một địa điểm, với vòng đời, các mặt hàng, lịch hẹn và một tổ ngoài hiện trường? Work Order (Lệnh công việc) của Field Service: Salesforce mô tả nó là công việc dịch vụ hiện trường được thực hiện cho khách hàng (WorkOrder (opens in a new tab), tiếng Anh). Chuyến ghé thăm theo lịch và khung giờ của nó là Service Appointment (Cuộc hẹn dịch vụ), và đó là thứ bộ phận điều phối xếp lịch và ứng dụng của tổ giao hàng hiển thị.
Vì vậy Giao hàng → Lệnh công việc. Không phải vì từ ngữ khớp nhau; chúng không khớp. Mà vì hành vi khớp với năng lực nền tảng mà chúng ta đã trả tiền và định sử dụng. Một đối tượng chuẩn không cần dùng chung từ vựng nghiệp vụ. Nó cần biểu diễn đúng khái niệm.
Bước 1 trên 4: phi thuyền mẹ. Mỗi thẻ là khái niệm nghiệp vụ, với đối tượng Salesforce của nó bên dưới.
Nhưng đối tượng chuẩn đi kèm hành lý
Phần tiêu đề “Nhưng đối tượng chuẩn đi kèm hành lý ”Nửa còn lại: Lệnh công việc không miễn phí. Nó mang theo giấy phép Field Service, các quan hệ riêng, hành vi bảo mật, trường bắt buộc, tự động hóa và vòng đời, và các phần khác của nền tảng mong đợi nó hành xử theo một cách nhất định. Chúng ta chọn nó vì sự phù hợp trọn vẹn và vì chúng ta dùng những gì được xây quanh nó. Nếu Steve Trucking không muốn gì từ Field Service và mô hình chống lại quy trình ở mọi bước, tôi sẽ cân nhắc lại. Kiến trúc là sự phù hợp, không phải cái nhãn.
Mặt hàng giao: đi theo mô hình
Phần tiêu đề “Mặt hàng giao: đi theo mô hình ”Một khi Giao hàng là Lệnh công việc, hãy xem phần còn lại của mô hình đó trước khi phát minh ra bất cứ thứ gì. Một Work Order Line Item (Mục dòng lệnh công việc) là một công việc con trên một lệnh công việc (WorkOrderLineItem (opens in a new tab), tiếng Anh): chiếc tủ lạnh, việc lắp đặt, việc chở đồ cũ đi. Vì vậy Mặt hàng giao → Mục dòng lệnh công việc. Để ý rằng quyết định đầu tiên đã định hình quyết định thứ hai. Chúng ta không chọn đối tượng cho từng thực thể một cách riêng lẻ. Hãy chấp nhận một mô hình, và hiểu phần còn lại của nó trước khi xây các cấu trúc tùy chỉnh quanh nó.
Đây là loại điểm dừng nào?
Phần tiêu đề “Đây là loại điểm dừng nào? ”Ở Steve Trucking, một điểm dừng là chỉ giao hàng, giao hàng kèm lắp đặt, hoặc giao hàng kèm chở đồ cũ đi, và mỗi loại có thời lượng, kỹ năng tổ giao hàng và danh sách kiểm tra lắp đặt riêng. Ở chương 2 chúng ta đã quyết định đó là một thực thể, không phải một nhãn. Field Service đã có sẵn: Work Type (Loại công việc), một mẫu cho một loại công việc có thể áp dụng cho lệnh công việc và các mục dòng (WorkType (opens in a new tab), tiếng Anh). Vì vậy Loại điểm dừng → Loại công việc. Một lần nữa, không phải vì có thứ gì đó tên là Work Type, mà vì khái niệm và hành vi khớp nhau.
Bước 2 trên 4: đi theo mô hình. Mục dòng và Loại công việc đi kèm Lệnh công việc.
Bảng kê hàng: giờ thì tôi muốn một đối tượng tùy chỉnh
Phần tiêu đề “Bảng kê hàng: giờ thì tôi muốn một đối tượng tùy chỉnh ”Có đối tượng chuẩn nào cho “danh sách của đối tác cho thứ Ba tại DC Phoenix” không? Không hẳn, và tôi sẽ không ép nó vào một đối tượng không liên quan chỉ để nói rằng chúng ta vẫn dùng chuẩn. Bảng kê hàng → Manifest__c. Đó là đơn vị tiếp nhận: nó đến từ đâu (một tệp, một lô API), khi nào, trạng thái và tổng số của nó, và khi một đối tác gửi lại trong ngày thì so sánh những gì. Mỗi dòng của bảng kê hàng trở thành một Lệnh công việc liên kết ngược về nó.
Tùy chỉnh không phải là thất bại. Đó là thứ nền tảng cho chúng ta khi một khái niệm không có chỗ chuẩn gọn gàng. Sai lầm không phải là tạo một đối tượng tùy chỉnh; mà là tạo nó mà không kiểm tra xem nền tảng đã có khái niệm đó chưa.
Bước 3 trên 4: đối tượng tùy chỉnh duy nhất, nơi không có đối tượng chuẩn nào phù hợp.
Ảnh: Salesforce lưu được không có nghĩa là nên lưu
Phần tiêu đề “Ảnh: Salesforce lưu được không có nghĩa là nên lưu ”“Chúng tôi cần ảnh giao hàng trong Salesforce.” “Trong Salesforce” nghĩa là gì? Người dùng cần xem chúng từ Salesforce, đúng. Điều đó có nghĩa là các tệp ảnh phải nằm trong bộ lưu trữ lõi không? Không nhất thiết. Hãy đếm các chữ số 0: khoảng bốn ảnh một lần giao, nhiều hơn với lắp đặt, với một triệu lần giao mỗi năm, là bốn đến năm triệu ảnh mỗi năm, và số lần giao tăng 30% mỗi năm.
Vì vậy lập trường xuất phát của tôi: đừng biến org lõi thành một kho ảnh khổng lồ chỉ vì người dùng cần truy cập ảnh. Các tệp thuộc về bộ lưu trữ được xây cho khối lượng đó, bên ngoài lõi, với Salesforce giữ những gì cần để tìm và hiển thị chúng: một tham chiếu, một số đếm, hoặc một bản ghi chỉ mục nhỏ cho mỗi ảnh, và một cờ cho biết các ảnh lắp đặt bắt buộc đã đủ. Quyền truy cập dữ liệu và nơi dữ liệu nằm về mặt vật lý là hai câu hỏi khác nhau. Đó là mô-đun 4 quay trở lại.
Trường: làm cho ý nghĩa hiện rõ
Phần tiêu đề “Trường: làm cho ý nghĩa hiện rõ ”Lệnh công việc cần các trường: mã tham chiếu của đối tác, khung giờ giao hàng, thời gian giao hàng thực tế, trạng thái, ghi chú như “mã cổng” hay “có chó trong sân”. Tôi sẽ không biến phần này thành một danh mục trường; mô-đun 6 đã làm việc đó. Hãy chạy các câu hỏi cho từng trường: nó có nghĩa là gì, ai sở hữu nó, nó có thay đổi không, nó là một mã định danh, một bộ từ vựng được kiểm soát, được lưu hay suy ra, có nhạy cảm không. Mã tham chiếu của đối tác là ID bên ngoài, nên tính duy nhất của nó là một phần của hợp đồng tích hợp, không chỉ là một ô đánh dấu. Thời gian giao hàng thực tế là một thời điểm, nên là Date/Time. Trạng thái điều khiển hành vi, nên là một danh sách được kiểm soát, không bao giờ là văn bản tự do. Và ghi chú giao hàng về nhà của một người là dữ liệu cá nhân, nên chúng được phân loại. Mỗi trường đều truy ngược được về ý nghĩa.
Quan hệ: đừng chỉ nối các hộp
Phần tiêu đề “Quan hệ: đừng chỉ nối các hộp ”Tài khoản đến Lệnh công việc, Lệnh công việc đến các mục dòng của nó, Bảng kê hàng đến Lệnh công việc, Loại công việc mô tả điểm dừng. Rồi các câu hỏi của mô-đun 7 cho từng đường: bản ghi con có tồn tại một mình được không, ai sở hữu nó, quyền truy cập có thừa hưởng không, nó có di chuyển được không, chuyện gì xảy ra khi xóa, có thể dồn lại bao nhiêu bản ghi con? Mọi Lệnh công việc nằm dưới một nhóm nhỏ tài khoản Đối tác bán lẻ nghĩa là hàng trăm nghìn bản ghi con cho mỗi bản ghi cha: một câu hỏi về lệch dữ liệu mà chúng ta sẽ trả lời ở Phần 2. Và với các quan hệ chuẩn của Field Service, hãy kiểm tra Salesforce đã xây chúng thế nào thay vì giả định chúng khớp với những gì chúng ta sẽ thiết kế. Khi bạn chấp nhận một mô hình chuẩn, bạn chấp nhận những quyết định Salesforce đã đưa ra bên trong nó. Hãy hiểu chúng trước khi xây lên trên.
Quyền sở hữu và Người nhận: đừng để giá trị mặc định quyết định
Phần tiêu đề “Quyền sở hữu và Người nhận: đừng để giá trị mặc định quyết định ”Hai quyết định mà một giá trị mặc định sẵn lòng đưa ra thay chúng ta.
Ai sở hữu một lần giao hàng? Chúng ta đã trả lời câu này ở mô-đun 8, và nó chuyển thẳng sang Lệnh công việc: ở đây quyền sở hữu không quyết định quyền truy cập của ai cả, nên người dùng tích hợp sở hữu các Lệnh công việc mà nó tạo ra. Điều phối viên thấy các lệnh của trung tâm phân phối của họ, tổ giao hàng thấy các lệnh trên tuyến của mình, và mỗi Đối tác bán lẻ thấy các lệnh của riêng mình qua cổng thông tin, tất cả nhờ chia sẻ, không phải nhờ quyền sở hữu. Người dùng tích hợp không có vai trò và nằm ngoài các nhóm công khai mà quy tắc chia sẻ của chúng ta dùng, vì với 3.300 mỗi ngày, nó vượt 10.000 bản ghi trong ba ngày. Và chúng ta ghi lại chuyện gì xảy ra nếu người dùng đó có lúc bị thay thế.
Người nhận là gì? Một Liên hệ? Một tài khoản cá nhân? Thứ gì đó chỉ được giữ trên lần giao hàng? Còn tùy vào việc Steve Trucking có quan hệ gì với những người này hay không (họ là khách hàng của các Đối tác bán lẻ), liệu một đối tác có bao giờ được thấy người nhận của đối tác khác không, dữ liệu cá nhân của họ được giữ bao lâu, và quy mô: khoảng một triệu Người nhận mới mỗi năm. Chúng ta chưa có đủ những điều đó, và điều đó không sao. Đôi khi câu trả lời đúng là chúng ta chưa biết đủ. Hãy ghi câu hỏi lại và đi tìm thông tin; đừng chôn sự không chắc chắn trong một đối tượng tùy chỉnh. Chúng ta trả lời nó ở điểm kiểm tra của Phần 1, sau khi các chương 4 đến 6 cho chúng ta bức tranh về doanh nghiệp và dữ liệu chủ.
Nhất quán: bảo vệ mô hình ở đúng tầng
Phần tiêu đề “Nhất quán: bảo vệ mô hình ở đúng tầng ”Nấc thang của mô-đun 9 được áp dụng: mã tham chiếu của đối tác là ID bên ngoài, duy nhất, nên một bảng kê hàng gửi lại sẽ upsert thay vì tạo bản trùng; trạng thái là một danh sách hạn chế; thời gian giao hàng thực tế chỉ bắt buộc khi trạng thái là Delivered; một điểm dừng lắp đặt không thể đóng khi thiếu danh sách kiểm tra và ảnh. Không phải một flow khổng lồ. Mỗi quy tắc trên nấc riêng của nó.
Mỗi phần nằm ở đâu
Phần tiêu đề “Mỗi phần nằm ở đâu ”Thêm một lượt nữa qua lát cắt, với câu hỏi của mô-đun 4: mỗi phần dữ liệu nằm ở đâu? Trong bộ slide lớp học của tôi, đó là một slide, logic đối chiếu với vật lý: các thực thể logic từ chương 2, và nơi mỗi thực thể thực sự nằm: trên lõi (on core), dưới dạng một sObject (__c nếu là tùy chỉnh) hoặc một đối tượng lớn (__b), hoặc ngoài lõi, dưới dạng một đối tượng bên ngoài (__x) hoặc dữ liệu không bao giờ đi vào Salesforce.
- Trên lõi, được dùng hằng ngày: Tài khoản, các Lệnh công việc và mục dòng của chúng, các Cuộc hẹn dịch vụ, các Loại công việc,
Manifest__c. - Trên lõi, đã lưu trữ: các lần giao hàng cũ hơn ba năm chuyển sang Lịch sử giao hàng (Delivery History), một đối tượng lớn, vẫn còn đó cho các khiếu nại, nhưng đã vào nhà kho phía sau.
- Được tham chiếu: chi tiết đơn hàng của chính Đối tác bán lẻ ở lại trong hệ thống của đối tác; chúng ta giữ mã tham chiếu của đối tác làm ID bên ngoài, và lấy phần còn lại qua một đối tượng bên ngoài hoặc qua tích hợp khi có người cần.
- Ngoài lõi: các ảnh, trong bộ lưu trữ được xây cho hàng triệu hình ảnh, với một liên kết từ Lệnh công việc.
Đó là mô hình vật lý: không chỉ là đối tượng nào, mà là ngôi nhà nào.
Giờ hãy nhìn toàn bộ lát cắt
Phần tiêu đề “Giờ hãy nhìn toàn bộ lát cắt ”- Đối tác bán lẻ → Tài khoản, với loại bản ghi Retail Partner; các quản lý DC là Liên hệ.
- Giao hàng → Lệnh công việc của Field Service, được xếp lịch qua một Cuộc hẹn dịch vụ.
- Mặt hàng giao → Mục dòng lệnh công việc.
- Loại điểm dừng → Loại công việc.
- Bảng kê hàng → đối tượng tùy chỉnh
Manifest__c. - Mã tham chiếu của đối tác → ID bên ngoài trên Lệnh công việc, duy nhất theo từng đối tác.
- Ảnh → lưu ngoài lõi; Salesforce giữ tham chiếu và cờ đủ ảnh.
- Lịch sử giao hàng → được lưu trữ vào một đối tượng lớn sau ba năm.
- Quyền sở hữu → người dùng tích hợp, với quyền truy cập qua chia sẻ (mô-đun 8).
- Người nhận → để ngỏ, cho điểm kiểm tra của Phần 1.
Bước 4 trên 4: toàn bộ lát cắt, trên lõi, đã lưu trữ và ngoài lõi. Mọi đường nối đều là quan hệ tra cứu: Salesforce xây Field Service trên các quan hệ tra cứu, và chúng ta chấp nhận các quyết định của nó cùng với nó.
Sơ đồ không phải là kiến trúc
Phần tiêu đề “Sơ đồ không phải là kiến trúc ”Tôi có thể đưa bạn sơ đồ đó, và nó không đủ. Kiến trúc là lập luận đằng sau nó. Tại sao là Tài khoản? Một công ty phù hợp trọn vẹn. Tại sao là Lệnh công việc mà không phải Delivery__c? Lần giao hàng hành xử như công việc hiện trường, và Field Service đã có sẵn. Tại sao Bảng kê hàng là tùy chỉnh? Không có chỗ chuẩn gọn gàng. Tại sao ảnh không chỉ là Files? Khối lượng và kinh tế lưu trữ. Tại sao là ID bên ngoài? Một hệ thống khác cần một danh tính ổn định qua ranh giới. Tại sao người dùng tích hợp sở hữu các Lệnh công việc? Ở đây quyền sở hữu không quyết định quyền truy cập, và điều đó giữ cho dấu vết kiểm toán trung thực. Tại sao Người nhận vẫn còn để ngỏ? Chúng ta chưa trả lời đủ câu hỏi. Các đường kẻ là đầu ra; các quyết định tạo ra chúng.
Vậy đây là thói quen tôi muốn bạn mang theo khi rời chương 3. Chỉ vào bất cứ thứ gì trong một mô hình vật lý và hỏi tại sao? Tại sao đối tượng này, kiểu này, quan hệ này, chủ sở hữu này, nơi này, quy tắc này? Bạn phải truy ngược được câu trả lời: từ cấu hình, đến mô hình vật lý, đến mô hình logic, đến yêu cầu nghiệp vụ. Nếu không làm được, ai đó đã thiết kế từ màn hình Thiết lập.
Và bạn hẳn đã để ý những con số chúng ta chưa tính hết: số lần giao mỗi đối tác, mục dòng, ảnh, lưu giữ, lưu trữ. Tốt. Hãy hỏi số chữ số 0 trước khi chốt một thiết kế: một mô hình chạy tuyệt đẹp với năm mươi nghìn bản ghi có thể hành xử rất khác với năm trăm triệu. Đó là Phần 2.
Ngoài kỳ thi: AI thay đổi điều gì. Đưa cho AI bản mô tả Steve Trucking và nó sẽ tạo ra một lược đồ trong vài giây: Tài khoản, Lệnh công việc, đối tượng tùy chỉnh, trường, thậm chí cả siêu dữ liệu triển khai. Đó là một bộ tăng tốc tuyệt vời, nhưng nó không phải là phần xem xét. Công việc của kiến trúc sư chuyển sang kiểm tra các ánh xạ và hệ quả của chúng: sự phù hợp, giấy phép, quyền sở hữu, vòng đời, quy mô, danh tính, bảo mật và những gì ở ngoài nền tảng. AI là tên lửa đẩy; nó không cho bạn biết bạn có đang hướng đúng phía hay không.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Mỗi khái niệm nghiệp vụ ánh xạ thế nào sang Salesforce: một đối tượng chuẩn, một đối tượng tùy chỉnh, hay thứ gì đó bên ngoài lõi.
- Những mã định danh, trường và quan hệ nào hiện thực ý nghĩa nghiệp vụ mà không lặng lẽ thay đổi nó.
- Hành vi nền tảng và giấy phép nào đi kèm một mô hình chuẩn bạn chấp nhận.
- Những quyết định nào về quyền sở hữu, vòng đời, nhất quán, lưu trữ và quy mô phải được đưa ra trước khi thiết kế hoàn tất.
- Những câu hỏi nào được để ngỏ một cách rõ ràng, thay vì bị giấu sau một lựa chọn hiện thực tùy tiện.
Ở đầu chương này chúng ta đã hỏi mô hình nên sống trên Salesforce thế nào. Đó là kiến trúc dữ liệu Salesforce: không phải tạo đối tượng, không phải thuộc lòng Thiết lập, không phải vẽ những chiếc hộp đẹp hơn, mà là chủ ý làm cho mô hình nghiệp vụ khớp với hình dáng của nền tảng. Mỗi cấu trúc là một cam kết. Hãy đưa ra những cam kết mà bạn có thể giải thích.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) và WorkType (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02.
- Bản mô tả Steve Trucking.