Ghi lại lý do, không chỉ kết quả
Bản ghi quyết định kiến trúc, thường gọi là ADR, mô tả một lựa chọn quan trọng cùng bối cảnh và hệ quả. Nhiều ADR hợp thành nhật ký quyết định để thành viên xem nhanh định hướng hoặc tìm hiểu sâu thiết kế. Theo hướng dẫn của AWS, ADR đã được chấp nhận nên được giữ nguyên; khi cần thay đổi, nhóm tạo bản ghi mới để thay thế. [1]
Gợi ý: mỗi bản ghi nên trả lời năm điểm gồm vấn đề cần giải quyết, ràng buộc hiện có, các phương án đã cân nhắc, lựa chọn cuối cùng và hệ quả dự kiến. Nội dung không cần dài, nhưng phải đủ để người không dự cuộc họp hiểu vì sao phương án phù hợp tại thời điểm đó, thay vì chỉ thấy tên công nghệ.
Chọn đúng quyết định cần lưu
Không phải mọi thay đổi mã nguồn đều cần ADR. Phạm vi phù hợp thường là quyết định có ảnh hưởng đáng kể đến cấu trúc hệ thống, yêu cầu phi chức năng, quan hệ phụ thuộc, giao diện hoặc công cụ xây dựng. Chỉnh sửa nhỏ, cục bộ và dễ hoàn tác có thể được ghi trong yêu cầu công việc hay nội dung rà soát mã. [1]
Gợi ý: doanh nghiệp nên đặt ngưỡng lập bản ghi dựa trên tác động. ADR đáng cân nhắc khi lựa chọn liên quan nhiều nhóm, thay đổi hợp đồng API, yêu cầu chuyển đổi dữ liệu, tạo phụ thuộc dài hạn hoặc làm phát sinh cách vận hành mới. Tiêu chí rõ ràng giúp nhật ký tập trung vào thông tin có giá trị lâu dài.
Liên hệ với mục tiêu kinh doanh
Tài liệu Microsoft nêu rằng thiết kế ứng dụng đám mây cần cân nhắc độ tin cậy, bảo mật, chi phí, vận hành và hiệu năng theo yêu cầu kinh doanh. Không có một kiểu kiến trúc phù hợp cho mọi hệ thống; sử dụng nền tảng đám mây cũng không đồng nghĩa ứng dụng bắt buộc phải chia thành microservices. [2]
Gợi ý: tránh ghi lý do chung chung như “hiện đại” hoặc “dễ mở rộng”. ADR nên nêu điều kiện cụ thể như đặc điểm tải, năng lực đội vận hành, giới hạn ngân sách, thời hạn triển khai và mức rủi ro có thể chấp nhận. Nhờ đó, người phụ trách sản phẩm có thể đánh giá lựa chọn theo mục tiêu doanh nghiệp thay vì sở thích kỹ thuật.
Quản lý trách nhiệm và vòng đời
Gợi ý: mỗi ADR nên có người phụ trách, ngày lập, trạng thái, người rà soát và liên kết đến yêu cầu liên quan. Tài liệu có thể nằm gần mã nguồn hoặc trong kho kiến thức có kiểm soát truy cập, miễn là đội phát triển, kiểm thử và vận hành tìm được bản hiện hành mà không phải hỏi lại người ra quyết định ban đầu.
Nhóm cũng nên quy định cách chuyển trạng thái từ đề xuất sang chấp nhận, từ chối hoặc thay thế. Khi giả định, yêu cầu bảo mật hay giới hạn nền tảng thay đổi, gợi ý là lập ADR mới, liên kết bản cũ và nêu nguyên nhân điều chỉnh. Việc đối chiếu ADR trong rà soát thiết kế giúp nhận diện thay đổi không còn phù hợp với quyết định đã thống nhất, nhưng không thay thế kiểm thử hoặc đánh giá bảo mật.
Ví dụ: lựa chọn lớp bảo vệ hệ thống
Ví dụ: khi thiết kế phần mềm lưu dữ liệu khách hàng, nhóm lập ADR để so sánh vị trí kiểm soát truy cập, cách quản lý bí mật, yêu cầu mã hóa và phương án ghi nhật ký truy cập. Bản ghi nêu rõ phạm vi dữ liệu, giả định về hạ tầng, trách nhiệm vận hành và ảnh hưởng đến chi phí. Đây là ví dụ thiết kế, không phải bảo đảm rằng một tập hợp biện pháp sẽ loại bỏ mọi rủi ro.
Gợi ý: ADR nên chỉ ra tín hiệu cần xem xét lại lựa chọn, chẳng hạn mô hình truy cập thay đổi, thành phần nền tảng ngừng được hỗ trợ hoặc yêu cầu kiểm soát mới xuất hiện. Khi điều chỉnh kiến trúc bảo vệ, bản ghi mới cần chỉ rõ quyết định bị thay thế để người tiếp quản hiểu cả lý do ban đầu lẫn nguyên nhân thay đổi.