Khi ba phòng ban của khách hiểu "đơn hàng" theo ba kiểu

Thử hình dung tuần đầu ở một công ty logistics. Bạn được giao xây một agent trả lời câu “hôm nay có bao nhiêu đơn hàng”. Phòng kinh doanh nói 420, kho nói 380, kế toán nói 350, và không bên nào sai.

Với phòng kinh doanh, “đơn hàng” là báo giá khách đã ký. Với kho, đó là phiếu soạn hàng. Với kế toán, đó là hoá đơn đã xuất. Ba con số trên chỉ là giả định, nhưng tình huống này rất hay gặp: một từ, ba mô hình, và code của bạn sẽ sai nếu chọn nhầm mô hình.

Domain-Driven Design Distilled của Vaughn Vernon giải đúng bài toán đó trong chưa tới 200 trang. Nếu việc của bạn là ngồi với chuyên gia nghiệp vụ của khách và biến cách họ nói thành một hệ thống chạy được, hãy đọc cuốn này trước những cuốn dày hơn.

Một cuốn mỏng, viết cho cả người không code

Sách do Addison-Wesley Professional xuất bản ngày 23/05/2016, ấn bản 1. Bản in dài 176 trang, ISBN-13 978-0-13-443442-1. Vernon dựa trên khoảng hai mươi năm áp dụng DDD vào tình huống thực tế. Phần giới thiệu sách nhấn mạnh rằng nó ngắn gọn, dễ đọc, làm theo được và không bắt người đọc ngập trong chi tiết.

Chi tiết đáng chú ý là đối tượng độc giả. Pearson ghi rõ sách dành cho lập trình viên, kiến trúc sư, analyst, tư vấn viên, và cả khách hàng. Với FDE, điều này dùng được ngay: bạn có thể đưa đúng một chương cho trưởng phòng vận hành của khách đọc, để khi họp hai bên dùng chung một bộ từ vựng.

Mục lục có 7 chương, mở đầu bằng “DDD for Me” và khép lại bằng “Acceleration and Management Tools”. Ở giữa là subdomain, context mapping, aggregate và domain event.

Ý thứ nhất: ngôn ngữ chung phải được xây cùng khách

Chương 2, “Strategic Design with Bounded Contexts and the Ubiquitous Language”, là phần quan trọng nhất của cuốn sách với FDE. Phần giới thiệu sách viết rằng ngôn ngữ chung được phát triển bên trong một bounded context xác định rõ. Sách hướng dẫn chuyên gia nghiệp vụ và lập trình viên cùng nhau tạo ra ngôn ngữ đó.

Chữ “cùng nhau” là điểm mấu chốt. Một glossary bạn tự viết sau buổi họp chỉ là bản dịch của riêng bạn. Glossary mà người kho tự tay sửa từng dòng mới là ngôn ngữ chung. Quay lại ví dụ logistics: khi người kho gạch chữ “đơn hàng” và viết “phiếu soạn”, bạn vừa tìm ra một ranh giới.

Việc nên làm đầu tiên ở khách: trong mỗi buổi discovery, ghi lại mọi danh từ nghiệp vụ. Sau đó hỏi: ai dùng từ này, và nó bắt đầu và kết thúc ở bước nào trong quy trình?

Ý thứ hai: tách mô hình, đừng gộp bằng mọi giá

Phản xạ của nhiều kỹ sư là tạo một bảng orders duy nhất cho cả công ty. Sách đi ngược lại phản xạ đó. Nó dạy cách tách các domain model bằng mẫu Bounded Context, để mỗi mô hình chỉ đúng trong ranh giới của nó.

Áp vào agent ở trên, câu trả lời đúng không phải một con số mà là ba: đơn đã ký trong context Kinh doanh, phiếu soạn trong context Kho, hoá đơn trong context Kế toán.

Agent cần hỏi lại xem người dùng đang nói theo context nào, hoặc tự chọn context theo vai trò của họ. Chỉ một quyết định thiết kế như vậy đã đủ tránh cả tuần tranh cãi “số liệu sai”.

Ý thứ ba: vẽ bản đồ trước khi viết integration

Khi đã có nhiều context, câu hỏi tiếp theo là chúng trao đổi với nhau ra sao. Chương 3 và 4, xoay quanh subdomain và context mapping, giúp trực tiếp việc vẽ ranh giới nghiệp vụ của khách. Với FDE, context map chính là bản thiết kế integration: phiếu soạn được tạo ra từ đơn đã ký như thế nào, hoá đơn lấy dữ liệu từ đâu.

Chương cuối giới thiệu các công cụ tăng tốc, trong đó có event storming. Bạn có thể chạy nó ngay trong một buổi workshop với khách để làm lộ ra các sự kiện nghiệp vụ và ranh giới, thay vì đoán từ schema cơ sở dữ liệu.

Hai lỗi dễ mắc nhất là gì?

Lỗi đầu tiên là tự viết glossary một mình rồi gửi khách “duyệt”. Người bận rộn thường gật đầu cho xong, nên những chỗ một từ mang hai nghĩa vẫn nằm im cho tới lúc agent trả lời sai. Cách sửa là để khách tự sửa định nghĩa ngay trong buổi họp, như người kho đã gạch chữ “đơn hàng”.

Lỗi thứ hai là suy mô hình từ schema cơ sở dữ liệu. Nếu chỉ có một bảng orders dùng chung, schema sẽ che mất việc ba phòng ban hiểu ba kiểu khác nhau. Hãy coi schema là thứ cần kiểm tra lại sau khi đã nghe người dùng nói, chứ đừng lấy nó làm điểm xuất phát.

Đọc theo thứ tự nào?

Nếu bạn sắp vào một engagement mới, hãy đọc chương 1 và 2 trước, vì đó là phần dùng được ngay từ buổi họp đầu tiên. Đọc tiếp chương 3 và 4 khi bắt đầu thiết kế integration, rồi đọc chương cuối khi cần tổ chức workshop.

Các chương về aggregate và domain event có thể để sau, đến lúc bạn thực sự viết code lõi. Đó là phần chiến thuật: hữu ích, nhưng chưa gấp với người còn đang tìm hiểu nghiệp vụ.

Làm sao để nhà tuyển dụng thấy kỹ năng này?

Khi đọc JD của các vị trí FDE, hãy dò những yêu cầu về mô hình hoá nghiệp vụ, chuyển yêu cầu kinh doanh thành hệ thống, hay làm việc trực tiếp với stakeholder của khách. Đó là những chỗ kỹ năng từ cuốn sách này đáng được nêu ra.

Trên CV, đừng viết “biết DDD”. Hãy viết điều kiểm chứng được, kiểu: “cùng đội vận hành của khách xác định ba bounded context, thống nhất định nghĩa đơn hàng, loại bỏ sai lệch số liệu giữa kho và kế toán”. Khi phỏng vấn, hãy kể lại đúng một lần bạn phát hiện một từ mang hai nghĩa.

Code tích hợp viết sai thì viết lại được. Một ranh giới vẽ sai từ tuần đầu thì sẽ đeo bám bạn suốt dự án.