Chốt nghĩa của "đơn hoàn thành" trước khi viết dòng SQL đầu tiên

Thử hình dung tuần thứ hai của bạn ở một công ty bán lẻ. Bạn demo dashboard “Đơn hoàn thành tháng này”, trưởng phòng kinh doanh gật đầu, còn kế toán trưởng nhíu mày vì con số cao hơn sổ của chị. Pipeline không có bug nào. Hai người chỉ đang đếm hai thứ khác nhau dưới cùng một cái tên.

Martin Fowler gọi đây là chuyện lặp lại hết dự án này đến dự án khác: từ đa nghĩa như “Customer” hay “Product” gây nhầm lẫn mãi không dứt. Với kỹ sư làm sản phẩm nội bộ, cái giá là vài cuộc họp.

Với FDE ngồi ở site khách, cái giá là lòng tin: người ta đã thấy một con số sai, những con số sau đó họ sẽ đọc với ánh mắt nghi ngờ.

Lý do phải xử lý chuyện này trước khi viết code rất đơn giản. Fowler viết rằng phần mềm không chịu được sự mơ hồ. Con người có thể nói “đơn hoàn thành” mà vẫn hiểu nhau trong ngữ cảnh. Còn một câu WHERE status = 'completed' thì buộc phải chọn đúng một nghĩa, và nó sẽ chọn lặng lẽ, không báo ai.

Vì sao một từ lại có ba nghĩa?

Alberto Brandolini, người tạo ra Event Storming, nói thẳng rằng thuật ngữ vốn mơ hồ: mỗi người diễn giải cùng một từ theo cách riêng, vì mỗi phòng ban có góc nhìn và nhu cầu khác nhau.

Một bài trên blog Codurance đưa ví dụ ngay trong một công ty: chuyên gia kinh doanh và chuyên gia kế toán có thể gắn hai khái niệm khác nhau vào cùng một từ.

Fowler còn chỉ ra một điều đáng nhớ hơn. Ranh giới giữa các ngữ cảnh nghiệp vụ thường không do kỹ thuật quyết định, mà chủ yếu do văn hoá con người: nhóm nào làm việc với nhau, phòng nào chịu trách nhiệm cái gì. Mỗi ngữ cảnh có thể có mô hình hoàn toàn khác cho cùng một khái niệm.

Vì thế mục tiêu của bạn không phải là thắng một cuộc tranh luận về nghĩa “đúng”. Tài liệu của Three Dots Labs nói rõ: cùng một từ mang nghĩa khác nhau ở các ngữ cảnh khác nhau là chuyện bình thường, miễn là ranh giới giữa các ngữ cảnh được vạch rõ.

Việc của FDE là làm cho từng nghĩa hiện ra, đặt tên cho nó và ghi rõ nó dùng ở đâu.

Một chữ “hoàn thành”, ba con số

Quay lại công ty bán lẻ giả định. Phòng kinh doanh coi đơn là hoàn thành khi khách thanh toán thành công. Phòng kho coi đơn hoàn thành khi hàng đã quét xuất kho và giao cho đơn vị vận chuyển. Kế toán chỉ coi đơn hoàn thành khi khách đã nhận hàng, hạn đổi trả đã qua và không có hoàn tiền.

Đưa số vào cho dễ thấy: giả sử tháng này có 1.000 đơn thanh toán thành công, 920 đơn đã xuất kho, 850 đơn đã qua hạn đổi trả mà không bị hoàn tiền. Dashboard của bạn đếm theo cột trạng thái thanh toán nên hiện 1.000. Kế toán ghi nhận 850. Khoảng lệch 150 đơn đó không phải lỗi dữ liệu mà là lỗi định nghĩa.

Giờ thêm một agent chăm sóc khách hàng trả lời câu “đơn của tôi hoàn thành chưa?”. Nếu agent đọc theo nghĩa của kinh doanh, nó sẽ báo “rồi” cho một đơn còn nằm trong kho. Cùng một lỗi định nghĩa, nhưng lần này nó đi thẳng tới khách cuối.

Glossary sau khi chốt cho ví dụ này có thể trông như sau:

Tên chuẩn	Phòng sở hữu	Quy tắc đo được	Trường dữ liệu	Ca biên đã chốt
Đơn đã thanh toán	Kinh doanh	Giao dịch thanh toán thành công	payment_status = 'captured'	Đơn COD tính khi nào?
Đơn đã xuất kho	Kho	Có lần quét xuất kho	shipped_at IS NOT NULL	Đơn giao một phần
Đơn đã chốt doanh thu	Kế toán	Đã giao, qua hạn đổi trả, không hoàn tiền	settled_at IS NOT NULL	Đơn đổi sang sản phẩm khác

Để ý rằng bảng này cố tình không còn chữ “hoàn thành”. Từ đây trở đi, chữ “hoàn thành” đứng một mình không được xuất hiện trong code, tên metric hay prompt của agent nữa.

Chốt glossary trong năm bước

Bước đầu là gom từ. Đọc ticket, tên bảng, tên cột, file Excel khách gửi, ghi chép các buổi họp, rồi đánh dấu những danh từ xuất hiện nhiều nhất. Những từ quen thuộc nhất như “khách hàng”, “đơn hàng”, “sản phẩm” thường là những từ nguy hiểm nhất, đúng như Fowler cảnh báo.

Bước hai, hỏi riêng từng chuyên gia nghiệp vụ, như Codurance khuyên. Đừng hỏi “hoàn thành nghĩa là gì?”, vì ai cũng sẽ trả lời chung chung. Hãy hỏi bằng ca biên: “Đơn bị hoàn một nửa có tính không?”, “Khách đổi size thì đơn cũ tính là gì?”. Chính những ca này làm lộ ra định nghĩa thật mà người ta đang dùng.

Bước ba, đưa các phòng vào cùng một buổi. Three Dots Labs coi Event Storming là một trong những cách tốt nhất để phát hiện và thống nhất từ vựng giữa developer và các bên liên quan.

Khi các sự kiện như “khách thanh toán”, “hàng xuất kho”, “hết hạn đổi trả” được dán theo thứ tự thời gian, ai cũng thấy chữ “hoàn thành” của mình nằm ở điểm nào trên dòng đó.

Bước bốn, đặt tên và gán chủ sở hữu. Mỗi nghĩa có một tên riêng, một phòng chịu trách nhiệm khi định nghĩa cần thay đổi, và một quy tắc mà máy chạy được. “Đơn ổn” không phải định nghĩa. “Có settled_at và không có bản ghi hoàn tiền” mới là định nghĩa.

Bước năm, đưa glossary vào hệ thống. Eric Evans gọi đích đến này là ubiquitous language: thứ ngôn ngữ chung, chặt chẽ giữa developer và người dùng nghiệp vụ, dùng y hệt trong cuộc họp lẫn trong code. Tên biến, tên cột, tên metric và mô tả tool của agent đều phải dùng tên chuẩn.

Công cụ giúp được ở bước này. Semantic layer của dbt cho phép định nghĩa metric một lần ở tầng mô hình hoá để mọi đơn vị kinh doanh dùng chung định nghĩa, bất kể họ dùng công cụ nào.

Khi định nghĩa đổi, thay đổi lan ra mọi nơi đang gọi nó. Ở Palantir, Ontology mô tả tổ chức khách hàng bằng đối tượng, thuộc tính và liên kết. Nhưng công cụ chỉ lưu định nghĩa, còn chọn định nghĩa nào vẫn là việc giữa người với người.

Những lỗi khiến glossary chết yểu

Lỗi phổ biến nhất là chọn nghĩa của người nói to nhất, hoặc của phòng đang trả tiền cho dự án. Phòng còn lại sẽ không cãi trong họp, mà lặng lẽ giữ file Excel riêng, và hệ thống của bạn thành hệ thống thứ hai không ai tin.

Lỗi thứ hai là glossary nằm trên wiki mà không đi vào code. Nếu cột vẫn tên is_completed, một kỹ sư mới vào sáu tháng sau sẽ dùng nó theo nghĩa họ đoán.

Lỗi thứ ba là đóng băng glossary. Fowler nhấn mạnh ngôn ngữ phải tiến hoá cùng hiểu biết của nhóm về domain, nên hãy ghi ngày chốt và người duyệt, rồi mở lại khi quy trình của khách thay đổi.

Biến kỹ năng này thành lợi thế nghề nghiệp

Khi đọc mô tả công việc FDE, để ý các cụm như “domain modeling”, “ontology”, “semantic layer” hay “work with business stakeholders”. Đó là dấu hiệu công ty cần đúng kỹ năng này.

Trong CV, đừng viết “giao tiếp tốt với khách”. Hãy viết một dòng có kết quả cụ thể, kiểu như đã chốt bộ định nghĩa metric với ba phòng ban và xoá được khoảng lệch giữa dashboard và sổ kế toán.

Trong phỏng vấn, chuẩn bị sẵn một câu chuyện về một thuật ngữ từng làm hai phòng hiểu lệch nhau: bạn phát hiện ra bằng cách nào, hỏi ca biên gì, và định nghĩa cuối cùng nằm ở đâu trong hệ thống. Một câu chuyện như vậy cho thấy bạn biết làm việc với cả dữ liệu lẫn con người, điều mà chính vai trò này đòi hỏi.

Bài tập: một cột trạng thái, một buổi chiều

Mở một bảng đơn hàng hoặc bảng khách hàng bạn đang làm, chạy SELECT DISTINCT trên cột trạng thái và liệt kê mọi giá trị nó đang chứa. Với mỗi giá trị, viết một câu hỏi ca biên kiểu “đơn bị hoàn một phần thì mang giá trị nào?”.

Mang danh sách đó đi hỏi người của hai phòng khác nhau, rồi điền kết quả vào một bảng năm cột như ví dụ ở trên. Chỗ nào hai người trả lời khác nhau, chỗ đó là dòng đầu tiên của glossary.

Code sai thì sửa được trong một buổi chiều. Một chữ bị hiểu sai đã nằm trong mọi bảng, mọi báo cáo và mọi câu trả lời của agent thì phải sửa cả trong đầu của khách, nên hãy chốt nghĩa của nó trước khi gõ WHERE đầu tiên.