Tại Sao Dev Không Thể Làm Dự Án Một Mình

Hỏi một nhóm developer tại sao dự án thất bại, bạn sẽ nghe những thứ quen thuộc: plan kém, scope creep, architecture tệ, test không đủ.

Hiếm khi ai nói: "Chúng tôi không hiểu vấn đề mình đang cố giải quyết."

Nhưng đó thường mới là nguyên nhân gốc rễ. Và nó chỉ ra một thứ mà hầu hết dev team đang đánh giá thấp — vai trò của domain expert trong dự án phần mềm.

Bạn Sẽ Học Được Gì

✅ Tại sao mọi dự án phần mềm đều bắt đầu từ một vấn đề thực tế, không phải từ một ý tưởng kỹ thuật
✅ Tại sao dev một mình không thể xác định chính xác vấn đề đó
✅ Domain expert thật ra làm gì trong một dự án (và tại sao không chỉ là requirement gathering)
✅ Cách Domain-Driven Design (DDD) đưa sự hợp tác này vào framework chính thức

Dự Án Tồn Tại Để Giải Quyết Vấn Đề

Trước khi viết một dòng code nào, trước khi design database schema, trước khi chọn tech stack — có một vấn đề.

Ai đó trong bệnh viện không thể theo dõi hồ sơ bệnh nhân hiệu quả. Một công ty logistics đang bị mất hàng vì hệ thống routing không handle được edge case. Một chủ doanh nghiệp nhỏ đang tốn bốn tiếng mỗi tuần để làm invoice thủ công — trong khi việc đó chỉ cần bốn phút.

Phần mềm không tồn tại tự nhiên. Nó ra đời để đáp ứng một nhu cầu thực tế.

Nghe thì hiển nhiên. Nhưng rất dễ quên giữa guồng quay hàng ngày của sprint, ticket, pull request. Khi bạn đang cắm đầu vào implementation, vấn đề ban đầu dễ bị đẩy ra sau — thay vào đó là những vấn đề kỹ thuật trước mắt, cụ thể hơn, cấp bách hơn.

Và khi điều đó xảy ra, bạn có nguy cơ build ra thứ gì đó rất ngon về mặt kỹ thuật, nhưng giải quyết sai vấn đề hoàn toàn.

Vấn Đề Phải Đến Trước Ý Tưởng

Có một sai lầm phổ biến trong dự án phần mềm: bắt đầu bằng solution.

"Mình sẽ build một mobile app."
"Nên thêm AI vào đây."
"Dùng microservices architecture đi."

Đây là những ý tưởng về solution — không phải vấn đề. Và nếu bạn bắt đầu từ solution, cả dự án sẽ xoay quanh việc justify nó, thay vì thật sự giải quyết bất cứ điều gì.

Thứ tự đúng phải là:

Vấn đề → Hiểu rõ → Solution → Implementation

Không phải:

Solution → Implementation → (hy vọng nó khớp với vấn đề nào đó)

Bạn hiểu vấn đề càng sâu, solution càng tốt — và bạn sẽ ít gặp dead end hơn. Những quyết định đưa ra sớm trong dự án sẽ theo bạn suốt. Hiểu sai từ đầu, bạn sẽ phải quay đầu sửa trong nhiều tháng.

Developer Không Phải Domain Expert

Đây là sự thật khó chịu: developer là expert trong việc build software, không phải trong domain mà software phục vụ.

Dev build hệ thống cho bệnh viện không biết y tá thật sự cần thấy gì vào đầu ca. Dev build phần mềm tài chính không tự nhiên hiểu tại sao các ràng buộc pháp lý tồn tại, và chúng ảnh hưởng thế nào đến quy trình thực tế. Dev build công cụ logistics không biết sự hỗn loạn thực sự của last-mile delivery.

Bạn có thể đọc tài liệu. Bạn có thể hỏi user. Bạn có thể cố hết sức.

Nhưng không có gì thay thế được người đã sống trong domain đó — người đã làm công việc đó, đã xử lý các edge case, đã cảm nhận sự friction của hệ thống cũ, và biết thứ nào thật sự quan trọng so với thứ chỉ trông có vẻ quan trọng trên giấy.

Người đó là domain expert.

Domain Expert Thật Ra Mang Lại Điều Gì

Domain expert không chỉ là người viết requirements rồi biến mất. Khi được tham gia đúng cách, họ mang đến thứ không thể thay thế ở từng giai đoạn:

Ở đầu dự án: Họ xác định vấn đề thật sự. Không phải triệu chứng bề mặt, không phải solution được giả định — mà là vấn đề cốt lõi mà dự án cần giải quyết. Nghe đơn giản nhưng thực ra không phải vậy. Hầu hết mọi người có thể mô tả điều đang làm họ bực bội; ít người có thể nói rõ tại sao nó đang xảy ra và một solution tốt trông như thế nào.

Trong giai đoạn design: Họ phát hiện hiểu lầm sớm. Dev có thể model "bệnh nhân" như một entity duy nhất. Domain expert trong healthcare biết rằng thực tế, một bệnh nhân có thể có nhiều care track song song, mỗi cái có quy tắc riêng. Insight đó — bắt được trong một buổi whiteboard — tránh được hàng tuần làm lại.

Trong giai đoạn implementation: Họ trả lời những câu hỏi không có trong ticket nào. "Điều gì xảy ra nếu một claim được submit sau deadline nhưng còn trong grace period?" — domain expert trả lời được trong 30 giây, trong khi không requirements document nào nghĩ đến điều đó.

Trong giai đoạn review: Họ xác nhận thứ được build có thật sự phản ánh thực tế không. Một hệ thống có thể đúng về mặt kỹ thuật mà vẫn sai — vì nó model domain không chính xác. Domain expert phát hiện điều này trước khi user phải chịu đựng nó.

Domain Expert Cần Ở Đó Suốt Dự Án

Đây là nơi nhiều dự án đi sai.

Domain expert tham gia buổi kickoff, giao requirements document, rồi trở thành "available nếu có câu hỏi." Dev team biến mất ba tháng rồi xuất hiện với thứ gì đó khớp phần nào với spec, nhưng bỏ lỡ hoàn toàn tinh thần của nó.

Domain expertise không phải thứ bạn download một lần là xong. Đó là một cuộc trò chuyện kéo dài suốt dự án.

Lý do đơn giản: software development đầy quyết định. Hàng nghìn quyết định nhỏ không bao giờ có trong spec. Edge case nào cần handle, cái nào bỏ. Cách model relationship giữa các entity. Phải làm gì khi data không khớp với kỳ vọng. Ưu tiên cái gì khi có xung đột yêu cầu.

Mỗi quyết định đó là một cơ hội để đi xa khỏi thực tế — hoặc bám sát nó. Và bạn chỉ bám sát được nếu có người hiểu thực tế đó đang ngồi cùng bạn.

Công việc của domain expert không phải viết code. Mà là làm la bàn — liên tục kiểm tra xem team có đang đi đúng hướng không.

Đây Chính Là Điều DDD Nói Đến

Domain-Driven Design (DDD) — approach được Eric Evans phát triển — thường được dạy như một tập hợp pattern: Entity, Value Object, Aggregate, Repository, Bounded Context.

Nhưng những pattern đó phục vụ một ý tưởng sâu hơn: phần mềm phải là model trung thực của domain mà nó phục vụ.

DDD không bắt đầu từ architecture. Nó bắt đầu từ hiểu domain thật sâu — tức là đưa domain expert và developer vào cùng một phòng, nói cùng ngôn ngữ, cùng nhau xây dựng shared model.

Một vài concept then chốt của DDD minh họa rõ điều này:

Ubiquitous Language. DDD yêu cầu developer và domain expert dùng cùng từ vựng. Không phải "user" và "account" khi business gọi họ là "client" và "policy." Đây không phải chuyện câu chữ — shared language buộc phải có shared understanding. Dùng từ khác nhau là đang nghĩ khác nhau, và sự khác biệt đó sẽ xuất hiện trong code.

Bounded Context. Các phần khác nhau của domain có thể dùng cùng từ với nghĩa khác nhau. "Customer" trong sales khác với "customer" trong billing, khác với "customer" trong support. DDD làm rõ ranh giới này — và điều đó chỉ xảy ra khi developer và domain expert cùng nhau map domain.

Model là cốt lõi. Trong DDD, domain model không phải database schema hay UML diagram — đó là sự hiểu biết chung của cả team về vấn đề, được diễn đạt trong code. Model đó chỉ chính xác khi cả hai phía — kỹ thuật và domain — cùng tham gia xây dựng.

Không có domain expert tham gia tích cực, DDD chỉ còn là một bộ pattern được áp dụng vào một vấn đề chưa được hiểu đúng.

Áp Dụng Trong Thực Tế

Không cần phải implement DDD bài bản. Các nguyên tắc này áp dụng được cho bất kỳ dự án nào:

• Đưa domain expert vào ngay từ khi xác định vấn đề — trước khi nói đến bất kỳ solution nào.
• Tổ chức các buổi review thường xuyên để dev demo thứ đã build và hỏi thẳng: "Đây có phản ánh đúng thực tế không?"
• Tạo shared glossary — khi một từ của business xuất hiện trong code, nó phải có cùng nghĩa ở cả hai bên.
• Coi thời gian của domain expert là resource của dự án, không phải nice-to-have. Book lịch cố định, giữ đều đặn.
• Hỏi "tại sao" nhiều hơn "cái gì." Khi domain expert nói thứ gì đó phải hoạt động theo cách nhất định, hãy hiểu lý do. Lý do thường quan trọng hơn quy tắc.

Nhìn Ra Bức Tranh Lớn

Software development thực chất là một quá trình dịch thuật. Bạn đang lấy thứ gì đó tồn tại trong thế giới thực — một vấn đề, một nhu cầu, một quy trình — và diễn đạt nó theo dạng máy tính có thể execute.

Bản dịch tốt đến đâu phụ thuộc vào mức độ người dịch hiểu cả hai ngôn ngữ. Ở đây: ngôn ngữ của domain, và ngôn ngữ của software.

Developer thành thạo một trong hai. Domain expert thành thạo cái còn lại.

Không ai làm được điều này một mình. Phần mềm tốt nhất được build khi cả hai phía thật sự đầu tư, thật sự giao tiếp, và cùng nhau hướng đến một cách hiểu chung về vấn đề.

Đó không phải triết lý quản lý. Đó là cách build phần mềm hữu ích thật sự hoạt động.