Phép thử khả năng đảo ngược
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 3 trong 7 của chương Tư duy như một kiến trúc sư dữ liệu, chương đầu tiên của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Mô hình dữ liệu là bộ xương · Tiếp theo: Kiến trúc là nghệ thuật đánh đổi
Câu hỏi mô-đun này trả lời: Làm sao phân biệt một quyết định kiến trúc với một quyết định thông thường?
Kiến trúc sư đưa ra rất nhiều quyết định.
Nhưng không phải quyết định nào cũng là quyết định kiến trúc.
Đó là một phân biệt quan trọng. Nếu coi mọi quyết định là kiến trúc, chúng ta sẽ dành hết thời gian tranh luận những thứ tương đối dễ thay đổi. Nếu không nhận ra những quyết định thực sự mang tính kiến trúc, chúng ta có thể đưa ra một quyết định năm phút hôm nay mà phải mất năm năm để gỡ.
Vậy làm sao phân biệt?
Tôi thích đặt một câu hỏi đơn giản:
Sau này đảo ngược quyết định này sẽ khó đến mức nào?
Tôi gọi đây là Phép thử khả năng đảo ngược.
Một thứ càng khó đảo ngược, và càng nhiều thứ khác phụ thuộc vào nó, thì nó càng xứng đáng được quan tâm về mặt kiến trúc.
Có những quyết định thay đổi rất rẻ
Phần tiêu đề “Có những quyết định thay đổi rất rẻ ”Hãy bắt đầu với một thứ đơn giản.
Chúng ta đặt tên một trường là Customer Category. Sáu tháng sau, phía nghiệp vụ nhận ra ai cũng gọi nó là Customer Segment. Chúng ta đổi nhãn. Có thể phải cập nhật một ít tài liệu và đào tạo người dùng một chút, nhưng đây không phải là một sự kiện kiến trúc lớn. Tuy vậy, chúng ta sẽ phải sống với tên API ban đầu, vì đổi nó có hệ quả lớn hơn nhiều. Vì vậy việc này có thể chỉ là xử lý một lần đổi nhãn, cùng sự nhầm lẫn có thể đi kèm.
Chúng ta đã quyết định. Chúng ta đổi ý. Chúng ta đi tiếp.
Giờ hãy so sánh với một quyết định khác.
Chúng ta tạo một mã định danh cho khách hàng. Chúng ta quyết định nó có ý nghĩa gì, dùng định dạng nào và hệ thống nào tạo ra nó. Rồi chúng ta công bố nó.
Salesforce dùng nó. Kho dữ liệu dùng nó. Nền tảng tích hợp dùng nó. Cổng thông tin khách hàng dùng nó. Năm ứng dụng khác bắt đầu lưu nó. Báo cáo và các đường ống dữ liệu dùng nó. Có thể cuối cùng khách hàng cũng nhìn thấy nó.
Ba năm sau, ai đó nói:
Có lẽ chúng ta không nên thiết kế mã định danh theo cách đó.
Đó là một cuộc trò chuyện rất khác.
Khác biệt không nằm ở chỗ quyết định này kỹ thuật hơn quyết định kia.
Khác biệt là khả năng đảo ngược.
Đây là cách chuyện đó có thể xảy ra. Giả sử doanh nghiệp tạo khóa bằng một phần tên khách hàng cộng một con số. Cách đó chạy tốt nhiều năm, vì chưa ai phải đổi tên. Rồi một năm hay lâu hơn sau đó, một cái tên thay đổi, và đột nhiên các khóa không còn khớp với mẫu mà phần còn lại của dữ liệu mong đợi. Đây là một trong những lý do khóa không nên mang bất kỳ ý nghĩa nội tại nào.
Kiến trúc tạo ra lực hấp dẫn
Phần tiêu đề “Kiến trúc tạo ra lực hấp dẫn ”Một quyết định kiến trúc có xu hướng tích tụ nhiều thứ xung quanh nó. Tôi nghĩ về điều đó như lực hấp dẫn.
Chọn một mô hình đối tượng, và tự động hóa được xây quanh nó.
Chọn một khóa, và các hệ thống khác bắt đầu lưu nó.
Chọn nơi dữ liệu chủ nằm, và các tích hợp bắt đầu chảy về phía nó và chảy ra từ nó.
Chọn một mô hình chia sẻ, và các quy trình nghiệp vụ bắt đầu phụ thuộc vào việc ai thấy được gì.
Chọn một mẫu tích hợp, và các hệ thống bắt đầu phụ thuộc vào thời điểm và hành vi của nó.
Những quyết định đó tồn tại càng lâu, lực hấp dẫn của chúng càng lớn. Cuối cùng, thay đổi quyết định ban đầu đồng nghĩa với thay đổi mọi thứ đã tích tụ quanh nó.
AI cũng chịu lực hấp dẫn đó. Một công cụ AI làm việc từ những gì đã có trong hệ thống: khi một yếu tố thiết kế then chốt đã nằm ở đó, mọi tương tác AI sau đó đều coi yếu tố đó là sự thật và tiếp tục xây trên nó, xây trên nó, xây trên nó. Quyết định ấy vang vọng về phía trước qua rất nhiều quyết định khác, và không con người nào quay lại xem xét quyết định ban đầu. Mỗi lần AI tạo ra thêm thứ gì đó lại làm lực hấp dẫn lớn thêm.
Đó là lý do việc mô hình dữ liệu là “bộ xương” lại quan trọng. Chúng ta cẩn thận không phải vì thay đổi là xấu. Chúng ta cẩn thận vì sự phụ thuộc làm cho thay đổi trở nên tốn kém.
Hãy đặt hai câu hỏi
Phần tiêu đề “Hãy đặt hai câu hỏi ”Khi xem xét một quyết định thiết kế, tôi đặt hai câu hỏi:
Đảo ngược điều này khó đến mức nào?
Bao nhiêu thứ sẽ phụ thuộc vào nó?
Hai câu này liên quan nhưng không giống nhau. Một thứ có thể dễ thay đổi về mặt kỹ thuật nhưng có hàng trăm bên sử dụng. Người ta từng đổi nhãn các đối tượng chuẩn cho rõ nghĩa, chẳng hạn Account thành “Customer”. Làm thì dễ. Rồi một hệ thống khác muốn dùng Account cho Đối tác, và không thể. Một thứ khác có thể chỉ có vài bên sử dụng nhưng cần một cuộc di chuyển dữ liệu khổng lồ để thay đổi, như tên API của một đối tượng được tham chiếu ở nhiều nơi trong nội bộ. Không ai bên ngoài nhìn thấy nó, nhưng một cái tên sai cứ khiến cả nhóm nhầm lẫn mãi. Cả hai đều đáng được quan tâm.
Hãy nghĩ về vài quyết định dữ liệu thường gặp:
- Đối tượng Salesforce nào biểu diễn khái niệm nghiệp vụ này?
- Mã định danh duy nhất là gì?
- Hệ thống nào là hệ thống gốc?
- Dữ liệu này được sao chép vào Salesforce hay được truy cập ở nơi khác?
- Đây là một đối tượng hay nhiều đối tượng liên quan?
- Ai sở hữu dữ liệu, và chúng ta giữ nó bao lâu?
- Ranh giới truy cập mặc định của chúng ta là gì?
- Dữ liệu này di chuyển giữa các hệ thống thế nào?
Những câu đó rất khác với việc quyết định một trường hiện ở đâu trên một trang Lightning. Thiết kế trang cũng quan trọng. Nhưng cái giá của việc sai là khác nhau.
Hãy nghĩ về phạm vi ảnh hưởng
Phần tiêu đề “Hãy nghĩ về phạm vi ảnh hưởng ”Một cách khác để nghĩ về khả năng đảo ngược là phạm vi ảnh hưởng: nếu tôi thay đổi quyết định này, những gì khác sẽ dịch chuyển theo?
Giả sử một thứ chúng ta mô hình hóa thành trường thực ra cần trở thành một đối tượng con. Đó không chỉ là một thay đổi lược đồ. Dữ liệu hiện có sẽ ra sao? Các báo cáo, các tích hợp đang chờ trường đó, Apex và các Flow tham chiếu đến nó, bảo mật, phân tích, một tác tử AI có hành động phụ thuộc vào cấu trúc ban đầu thì sao?
Phạm vi càng lớn, chúng ta càng nên đưa ra quyết định ban đầu một cách cẩn thận.
Đó cũng là lý do kiến trúc sư phải nhìn ra ngoài phần hệ thống của mình. Từ bên trong Salesforce, một thay đổi có thể trông dễ dàng. Từ góc nhìn doanh nghiệp, nó có thể ảnh hưởng đến mười hai hệ thống khác.
Quyết định cấp doanh nghiệp và quyết định trong Salesforce
Phần tiêu đề “Quyết định cấp doanh nghiệp và quyết định trong Salesforce ”Một Data Architect suy nghĩ ở hai cấp.
Bên trong Salesforce, chúng ta quyết định đối tượng, quan hệ, khóa, khối lượng, truy cập, tự động hóa và cách dữ liệu hoạt động trên nền tảng.
Trên toàn doanh nghiệp, chúng ta đặt những câu hỏi rộng hơn. Khách hàng thực sự nằm ở đâu? Ai sở hữu Sản phẩm? Hệ thống nào tạo Đơn hàng? Mã định danh có thẩm quyền của chúng ta là gì? Thông tin nào được sao chép giữa các hệ thống, và thông tin nào ở yên tại chỗ?
Hai cấp này phải kết nối với nhau. Tôi từng thấy những dự án triển khai Salesforce mà mô hình nội bộ tự nó hoàn toàn hợp lý nhưng lại không khớp với doanh nghiệp xung quanh. Như vậy là chưa đủ. Các cấu trúc Salesforce cần được biểu diễn ở cấp doanh nghiệp, và các quyết định cấp doanh nghiệp cần chảy ngược vào Salesforce.
Kiến trúc là giao thông hai chiều.
Hãy chậm lại với những quyết định tốn kém
Phần tiêu đề “Hãy chậm lại với những quyết định tốn kém ”Một mối nguy trong công nghệ là những quyết định dễ triển khai nhất có thể trông như những quyết định dễ đưa ra nhất. Chúng không giống nhau.
Tạo thêm một đối tượng tùy chỉnh thì dễ. Tạo thêm một trường thì dễ. Kết nối thêm một API ngày càng dễ, và AI còn làm mọi thứ dễ hơn nữa.
Nhưng sự dễ dàng khi triển khai gần như không cho chúng ta biết gì về cái giá của quyết định kiến trúc.
Trước một quyết định khó đảo ngược, hãy chậm lại đủ lâu để hỏi: Chúng ta thực sự đang giải quyết vấn đề gì? Chúng ta đã cân nhắc những phương án nào? Chúng ta đang giả định điều gì? Điều gì xảy ra khi khối lượng tăng, và khi việc kinh doanh thay đổi? Còn gì khác sẽ phụ thuộc vào điều này? Điều gì xảy ra nếu chúng ta sai?
Chúng ta không cần sáu tháng xem xét mỗi lần tạo một đối tượng. Nhưng chúng ta cần suy nghĩ tương xứng với cái giá của việc làm sai. Nếu đó là đối tượng cho một phòng ban hay một hệ thống con, bạn có thể đi nhanh hơn. Nếu đó là dữ liệu tham chiếu, một đối tượng khách hàng then chốt hay thứ gì đó được dùng xuyên hệ thống, hãy dành thời gian suy nghĩ thấu đáo.
Hãy ghi lại lý do
Phần tiêu đề “Hãy ghi lại lý do ”Những quyết định quan trọng còn một vấn đề khác: người ta quên mất vì sao chúng được đưa ra.
Ba năm sau, ai đó nhìn vào một kiến trúc và hỏi: “Sao lại có người thiết kế thế này?” Đôi khi câu trả lời là đó là một thiết kế tồi. Chuyện đó có xảy ra. Nhưng đôi khi đã có một lý do rất chính đáng: một giới hạn nền tảng nay không còn nữa, một yêu cầu pháp lý, một hệ thống khác không hỗ trợ được cách làm ưu tiên, một đánh đổi được chấp nhận có ý thức để kịp hạn chót.
Nếu chúng ta chỉ ghi lại cái gì đã quyết mà không ghi tại sao, kiến trúc sư tiếp theo không có cách nào biết được.
Với những quyết định quan trọng, hãy ghi lại. Không cần đến tài liệu 50 trang. Một hồ sơ quyết định hữu ích có thể rất nhỏ:
Bối cảnh: Chúng ta đang giải quyết vấn đề gì?
Phương án: Chúng ta đã cân nhắc những phương án thực tế nào?
Quyết định: Chúng ta đã chọn gì?
Hệ quả: Chúng ta được gì, và đang từ bỏ điều gì?
Người chịu trách nhiệm: Ai chịu trách nhiệm về quyết định này?
Xem xét lại: Lý do hay mốc thời gian nào sẽ khiến chúng ta xem lại nó?
Giá trị không nằm ở tài liệu. Giá trị nằm ở việc lưu giữ lập luận.
Và khi một quyết định thay đổi, đừng xóa quyết định ban đầu. Hãy thay thế nó bằng quyết định mới. Quyết định đúng vào năm 2027 có thể không còn đúng vào năm 2030, vì khối lượng, việc kinh doanh, Salesforce và hiểu biết của chúng ta đều thay đổi. Điều tôi muốn giữ lại là câu chuyện: đây là bối cảnh, đây là quyết định và lý do, đây là những gì đã thay đổi, và đây là điều chúng ta đang quyết định bây giờ. Điều đó giá trị hơn nhiều so với việc giả vờ rằng chúng ta luôn biết câu trả lời.
Ngoài kỳ thi: AI rút ngắn thời gian từ quyết định đến sự phụ thuộc. Một công cụ AI có thể đề xuất một mô hình dữ liệu trong vài giây, rồi tạo các đối tượng, tự động hóa, mã tích hợp và giao diện người dùng bên trên nó. Một quyết định đáng ngờ trước đây cần nhiều tháng phát triển trước khi có nhiều thứ phụ thuộc vào nó; giờ sự phụ thuộc đến gần như ngay lập tức. Vì vậy hãy xem xét những quyết định bên dưới kết quả, chứ không chỉ kết quả. AI có thể giúp: nó có thể liệt kê phương án, chất vấn giả định và soạn nháp hồ sơ quyết định. Nhưng kiến trúc sư vẫn là người quyết định, và quyết định càng khó đảo ngược thì óc phán đoán của con người càng quan trọng.
Biết quyết định nào quan trọng
Phần tiêu đề “Biết quyết định nào quan trọng ”Một trong những kỹ năng tôi muốn bạn phát triển là biết nên dồn sự chú ý vào đâu.
Đừng biến mọi lựa chọn cấu hình thành một hội nghị thượng đỉnh kiến trúc.
Nhưng cũng đừng tùy tiện đưa ra một quyết định mà tổ chức sẽ phải sống cùng trong mười năm tới.
Hãy hỏi:
Đảo ngược điều này sẽ khó đến mức nào?
Bao nhiêu thứ sẽ phụ thuộc vào nó?
Nếu câu trả lời là rất khó và rất nhiều, có lẽ bạn đã tìm thấy một quyết định kiến trúc.
Hãy chậm lại. Hiểu yêu cầu. Khám phá các phương án. Làm cho các đánh đổi hiện rõ. Đưa ra quyết định. Và ghi lại lý do.
Mục tiêu của kiến trúc không phải là đưa ra những quyết định không bao giờ thay đổi.
Mục tiêu là nhận ra những quyết định mà đổi ý sẽ rất tốn kém.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Quyết định nào mang tính kiến trúc: khó đảo ngược, với nhiều thứ phụ thuộc vào nó.
- Mỗi quyết định nhận được bao nhiêu sự chú ý, tương xứng với cái giá của việc làm sai.
- Quyết định nào được ghi lại, cùng bối cảnh, phương án, hệ quả, người chịu trách nhiệm và mốc xem xét lại.
- Các quyết định trong Salesforce khớp với các quyết định của doanh nghiệp thế nào.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Object Relationships Overview (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-09; kiểm tra lại ngày 2026-10-12): trong quan hệ chính-chi tiết, quyền truy cập và quyền sở hữu của bản ghi chi tiết đi theo bản ghi chính, và xóa bản ghi chính sẽ xóa các bản ghi chi tiết của nó.
- Considerations for Object Relationships (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-09; kiểm tra lại ngày 2026-10-12): một quan hệ tra cứu chỉ chuyển được thành chính-chi tiết khi mọi bản ghi đều có giá trị ở đó; việc chuyển đổi làm thay đổi mô hình chia sẻ (thành Controlled by Parent), và loại quan hệ quyết định những loại báo cáo chuẩn nào có sẵn.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-09; kiểm tra lại ngày 2026-10-12): trường tổng hợp cuộn lên chỉ tồn tại trên quan hệ chính-chi tiết, và phải bị xóa trước khi một quan hệ chính-chi tiết có thể thành quan hệ tra cứu.