Blackboards — Khi Code Nói Chuyện Qua Một Cái Bảng Đen (Pragmatic Programmer #36) | Blog

Mở đầu

Hè mấy bạn, mình lại lên đây tiếp tục series đọc sách "The Pragmatic Programmer" rồi nè. Hồi đầu mình cứ nghĩ sách dạy lập trình thì xoay quanh code, syntax, framework các thứ. Càng đọc càng thấy cuốn này nó khác — nó dạy về tư duy làm phần mềm hơn là cú pháp. Và topic hôm nay là một trong những cái khiến mình phải ngẫm nghĩ nhiều nhất: Blackboards.

Ảnh: fauxels — Pexels

Tựa đề nghe có vẻ cổ điển như cái bảng đen hồi đi học, nhưng thực ra nó là một architectural pattern khá mạnh mẽ mà tụi mình ít khi để ý tới.

Blackboards — Cái Bảng Đen Kỳ Diệu

Ý tưởng của Blackboard pattern thực ra rất đơn giản: thay vì các module trong hệ thống phải biết mặt biết tên, gọi qua gọi lại lằng nhằng, thì tụi nó chỉ cần một khu vực chung — cái blackboard — để đọc và ghi dữ liệu vào. Không cần biết ai viết, không cần biết ai đọc. Chỉ cần viết lên bảng, và ai cần thì xài.

Trong sách, tác giả ví von rất hay: hãy tưởng tượng một căn phòng với cái bảng đen ở giữa, và một đội thám tử đang điều tra vụ án giết người. Một thám tử hỏi "Ai là thủ phạm?" và viết lên bảng. Người khác đến, thêm chứng cứ, thêm lời khai nhân chứng. Một thám tử khác từ ca đêm tới, thấy manh mối mới trên bảng, liền phát hiện ra mối liên hệ và viết tiếp. Từ từ, vụ án được phá nhờ công sức của nhiều người, nhiều ca, nhiều góc nhìn khác nhau — mà chẳng ai cần biết mặt ai.

Ảnh: Ketut Subiyanto — Pexels

Ý tưởng này ban đầu ra đời từ dự án Hearsay-II về nhận dạng giọng nói vào những năm 1970. Một module xử lý âm thanh thô, module khác nhận diện từ, module khác phân tích ngữ pháp — mỗi module là một chuyên gia trong một lĩnh vực, và chúng giao tiếp với nhau thông qua một blackboard chung. Đây là một trong những ứng dụng AI đầu tiên của pattern này.

Ba đặc điểm chính của Blackboard pattern:

Không biết nhau: Các module không cần biết sự tồn tại của nhau. Giống mấy ổng thám tử, ai cũng chỉ nhìn vào bảng.
Kỹ năng khác nhau: Mỗi module có chuyên môn riêng, làm việc độc lập.
Không giới hạn nội dung: Trên blackboard có thể là text, object, bất cứ thứ gì.

Trong thế giới hiện đại, khái niệm này được hiện thực hóa qua tuple spaces — những key-value store mà các process có thể đọc/ghi bất đồng bộ. Linda, JavaSpaces, hay Redis Pub/Sub là những ví dụ thực tế. NHưng rộng hơn nữa, cả shared database trong kiến trúc microservices cũng mang tinh thần của blackboard: các service ghi dữ liệu vào DB chung và đọc dữ liệu của nhau.

Một ví dụ kinh điển trong sách: bạn có một tool network monitoring, các agent thu thập performance statistics và trouble reports khắp nơi. Mỗi agent ghi dữ liệu lên blackboard độc lập. Một agent khác — hoặc một con người — có thể đọc toàn bộ dữ liệu để phát hiện pattern bất thường. Từng metric riêng lẻ có thể vô hại, nhưng tổ hợp vài số liệu mới báo hiệu sự cố. Blackboard là nơi duy nhất cho phép nhìn được bức tranh toàn cảnh.

Ảnh: RDNE Stock project — Pexels

Tuy nhiên, không phải chỗ nào cũng xài blackboard được. Image processing chia ảnh ra nhiều chunk để xử lý song song? Không cần blackboard — một hàng đợi (queue) đơn giản là đủ, vì mỗi chunk độc lập, kết quả không ảnh hưởng lẫn nhau. Còn group calendaring (lên lịch họp cho nhiều người ở nhiều múi giờ), mỗi người đặt availability, người khác thấy rồi điều chỉnh — đó mới xứng đáng xài blackboard.

Cảm nhận của mình

Cái mình thích nhất ở topic này là sự đối lập: khi architecture càng ngày càng phức tạp, người ta có xu hướng thêm nhiều interface, nhiều abstraction, nhiều tầng lớp để giao tiếp giữa các module. Trong khi đó, blackboard pattern lại đi theo hướng ngược lại — giảm giao tiếp đến mức tối thiểu. Một bảng đen. Không API, không callback, không dependency.

Mình từng làm một dự án mà nhóm ai cũng viết module của riêng mình, rồi quăng lên một cái message queue. Lúc đó mình không biết đó gọi là blackboard pattern. Giờ đọc lại mới thấy à thì ra mình đã xài pattern này từ lúc nào không hay. Quả thực nó giúp giảm coupling khủng khiếp. Module A có bug, mình tắt nó đi sửa, các module khác vẫn chạy bình thường, chỉ là không có dữ liệu từ A nữa thôi.

Tuy nhiên, mình cũng thấy rằng blackboard pattern không phải chuyện đùa khi apply vào production. Một blackboard không có kiểm soát dễ biến thành bãi chiến trường — ai cũng viết, ai cũng đọc, không ai dọn dẹp. Dữ liệu cũ chất đống. Không có cơ chế đồng bộ dễ dẫn đến race condition. Cho nên pattern này cần đi kèm với một rules engine hoặc một cơ chế kiểm soát truy cập hợp lý.

Nói chung, đây là một topic mà mình thấy cực kỳ giá trị — nó mở rộng tư duy về cách các phần trong hệ thống có thể giao tiếp với nhau mà không cần biết mặt nhau. Trong thời đại microservices, serverless, event-driven architecture đang lên ngôi, blackboard pattern có lẽ là một trong những ý tưởng còn nguyên giá trị sau 20 năm.

Kết

Topic 36 — Blackboards là một bài học về decoupling ở cấp độ cao nhất: khi các module không cần biết nhau tồn tại, chỉ cần một không gian chung để chia sẻ. Đơn giản nhưng mạnh mẽ.

Hẹn mấy bạn ở bài sau nha! Mình sẽ tiếp tục với Chapter 7: While You Are Coding. Chắc chắn sẽ còn nhiều điều hay ho lắm. 👋