- Lập luận rằng phần lớn những bài toán khó cốt lõi của phát triển phần mềm không phát sinh bên trong mã nguồn, mà ở ranh giới (Boundary) nơi mã với mã, hệ thống với hệ thống gặp nhau
- Ranh giới = điểm mà các mối quan tâm, trách nhiệm và ngữ cảnh khác nhau gặp nhau
- Gần như mọi hành vi trong phát triển như tách hàm, mô-đun hóa, microservice đều là hành vi tạo ra ranh giới
- Nghịch lý: ta tạo ra ranh giới để xử lý sự phức tạp, nhưng bản thân ranh giới lại trở thành nguồn gốc của sự phức tạp mới
Các ranh giới phát sinh trong code
- Ranh giới caller-callee: sự mơ hồ của hợp đồng như trả về
null hay ném ngoại lệ
- Ranh giới interface: định luật rò rỉ trừu tượng - độ phức tạp bị che giấu rồi sẽ có lúc trồi lên xuyên qua ranh giới
- Ranh giới phụ thuộc: API và thư viện bên ngoài có thể thay đổi mà không báo trước
- Ranh giới chuyển đổi: như sự không tương thích trở kháng object-relational, mỗi lần vượt qua ranh giới là mỗi lần thông tin bị méo mó hoặc mất mát
- Ranh giới tin cậy: ranh giới giữa dữ liệu đã được xác thực và chưa được xác thực → lỗ hổng bảo mật như nhận webhook không có chữ ký
- Ranh giới thiết kế-thực thi: từ yêu cầu → thiết kế → triển khai → vận hành, tổn thất thông tin tích lũy ở mỗi giai đoạn
Các ranh giới vật lý
- Ranh giới thứ tự: trạng thái có thể thay đổi giữa các điểm bất đồng bộ, và trong hệ thống phân tán thì còn nghiêm trọng hơn
- Ranh giới quy mô: khi vượt qua điểm tới hạn, thay đổi xảy ra không còn là thay đổi về lượng mà là thay đổi về chất
- Ranh giới môi trường: phát sinh những chuyện kiểu “trên máy tôi thì chạy bình thường”
- Ranh giới hạ tầng: khi tách dịch vụ thì không thể bảo đảm tính nguyên tử
Các ranh giới phát sinh giữa con người
- Ranh giới tổ chức: định luật Conway - cấu trúc tổ chức quyết định cấu trúc hệ thống. Khi tái cơ cấu nhóm, ranh giới mã nguồn và ranh giới tổ chức bị lệch nhau
- Ranh giới giao tiếp: giống trò truyền miệng, mỗi lần yêu cầu được truyền đi thì ý định lại bị biến dạng, còn tri thức ngầm thì thậm chí không được truyền đạt
- Ranh giới người dùng-nhà phát triển: ranh giới mà nhà phát triển tạo ra để đảm bảo an toàn lại trở thành rào cản phiền phức với người dùng
Cách kiểm soát ranh giới
- Nhận diện ranh giới bị che giấu: chú ý tới các liên kết không thấy được trong code, như hai dịch vụ cùng chia sẻ một bảng DB
- Pattern không phải là đáp án: pattern chỉ là “giải pháp hiệu quả trong những điều kiện nhất định”, không được áp dụng một cách mù quáng
- Ba câu hỏi cần đặt ra trước ranh giới:
- Điều gì đang đi qua ranh giới này?
- Nếu ranh giới này bị phá vỡ thì chuyện gì sẽ xảy ra?
- Ai là người quản lý ranh giới này?
- Không vạch ra ranh giới cũng là một lựa chọn: giữ monolith, tránh tách sớm một cách hấp tấp
- Ranh giới tiến hóa theo thời gian: tách ra rồi nhập lại, nhập lại rồi lại chia ra → cần rà soát một cách có chủ đích và định kỳ
Chưa có bình luận nào.