Lát cắt đầu hoạt động tạo thêm câu hỏi: phân quyền ở đâu, thông báo xử lý thế nào, khách hàng muốn quy trình khác thì phần nào trở nên khó? Kiến trúc là tập quyết định quan trọng định hình các câu trả lời ấy. Sơ đồ giúp giao tiếp nhưng thêm nhiều hộp không khiến hệ thống tự bền bỉ hơn.
Chương 2 bàn giao quy trình quản lý yêu cầu hẹp. Ở đây, ta dùng AI khám phá kiến trúc nhưng vẫn gắn quyết định với ràng buộc thực của sản phẩm. Công cụ giả định tiếp tục nhỏ có chủ đích. Chỉ thêm hạ tầng khi yêu cầu cụ thể khiến chi phí đáng bỏ ra.
Bắt đầu từ các lực tác động lên hệ thống
Liệt kê yêu cầu ảnh hưởng cấu trúc. Người dùng thuộc tổ chức; yêu cầu có thể chứa chi tiết vận hành nhạy cảm; điều phối viên cần lưu đáng tin. Nhóm nhỏ phải tự triển khai, chẩn đoán và hỗ trợ ứng dụng mà không có phòng hạ tầng riêng.
Phân biệt yêu cầu với sở thích. “Cách ly dữ liệu tổ chức” là yêu cầu. “Dùng microservice” là lựa chọn cần lý do. “Thông báo cuối cùng phải được gửi tin cậy” có thể thành yêu cầu khi đó là phần đã hứa, không nên tự trở thành yêu cầu chỉ vì tác nhân đề xuất hàng đợi.
Nhờ AI tóm tắt các lực và tìm xung đột. Câu trả lời hữu ích giải thích đánh đổi như bàn giao nhanh và độ phức tạp vận hành. Kiểm tra tóm tắt với bối cảnh kinh doanh trước khi yêu cầu thiết kế.
Vẽ ranh giới quanh trách nhiệm
Thiết kế đơn giản có thể gồm giao diện web, lớp ứng dụng và cơ sở dữ liệu quan hệ. Trong ứng dụng, phân biệt thao tác yêu cầu, danh tính và phân quyền, cùng xử lý thông báo về sau. Ranh giới logic có thể nằm trong một ứng dụng triển khai chung, không bắt buộc dịch vụ riêng.
Với từng ranh giới, giải thích nó sở hữu gì và được giả định gì. Thao tác yêu cầu quản lý kiểm tra và chuyển trạng thái. Phân quyền quyết định người gọi được thao tác trên tổ chức và bản ghi cụ thể hay không. Lưu trữ thực thi ràng buộc cần để dữ liệu nhất quán.
Dùng AI phản biện bằng yêu cầu thay đổi cụ thể. “Thêm lịch sử phân công thì ghi ở đâu?” hữu ích hơn “Kiến trúc này có mở rộng được không?”. Câu trả lời cần cho thấy độ phụ thuộc và người chịu trách nhiệm, không chỉ ca ngợi mẫu thiết kế quen thuộc.
Để mô hình dữ liệu giải thích quy trình
Biểu diễn trạng thái sản phẩm thực dùng: mở, đã phân công, hoàn tất. Định nghĩa chuyển trạng thái nào được phép và ai được làm. Nếu cần mở lại yêu cầu hoàn tất, quyết định sửa bản ghi gốc hay ghi sự kiện mới.
Giữ mã tổ chức ở nơi hỗ trợ cách ly và kiểm tra quan hệ phía máy chủ. Khóa ngoại chứng minh người được giao tồn tại, nhưng chưa chắc chứng minh họ thuộc tổ chức của người gọi. Phân quyền và toàn vẹn quan hệ giải quyết vấn đề liên quan nhưng khác nhau.
Yêu cầu ví dụ trạng thái không hợp lệ. Yêu cầu hoàn tất không có người phụ trách có thể hợp lệ ở quy trình này nhưng sai ở quy trình khác. Nhóm phải quyết định. Mã hóa quy tắc trước khi thảo luận dễ tạo chính sách vô tình mà người dùng sau xem là giới hạn sản phẩm.
So sánh phương án trong cùng tình huống
Bắt đầu từ phương án cơ sở đáng tin
Dùng thiết kế đơn giản nhất đáp ứng yêu cầu đã biết và có thể vận hành có trách nhiệm. Ứng dụng chia mô-đun với một cơ sở dữ liệu có thể đủ. Nêu giới hạn như hệ quả khi cơ sở dữ liệu ngừng hoặc khả năng môi trường triển khai.
Thêm một phương án khi có lực đủ mạnh
Nếu thông báo phải tiếp tục sau lỗi tạm thời của nhà cung cấp email, so sánh gửi đồng bộ với cơ chế tác vụ bền vững. Đánh giá thử lại, gửi trùng, giám sát và công sức hỗ trợ. Thành phần mới phải giải bài toán có tên, không chỉ tạo sơ đồ ấn tượng.
Ghi lý do lựa chọn
Bản ghi quyết định ngắn gồm bối cảnh, phương án, lựa chọn, hệ quả và điều kiện xem lại. AI có thể soạn, nhưng kỹ sư chịu trách nhiệm phải xác minh nó phản ánh đúng quyết định thực của nhóm.
Thiết kế hành vi lỗi cùng luồng thành công
Hỏi điều gì xảy ra khi người dùng gửi lại, thao tác dữ liệu hết thời gian hoặc dịch vụ ngoài trả lời muộn. Trình duyệt báo lỗi không chứng minh máy chủ chưa lưu. Thử lại thao tác chưa rõ kết quả có thể tạo bản sao nếu không thiết kế chịu lặp.
Khi tạo yêu cầu, có thể dùng mã thao tác do phía khách tạo cùng ràng buộc duy nhất phía máy chủ. Giữ kết quả gắn với mã để lần thử lại trả cùng kết quả. Cách triển khai tùy nền tảng và quy trình; yêu cầu kiến trúc là có kết quả xác định khi lặp.
Khi quy trình qua nhiều hệ thống, chỉ ra nguồn chính thức và tình trạng giữa các bước. Giao dịch dữ liệu cục bộ không đồng thời cam kết email ngoài. Giải thích phục hồi quy trình dở dang trước khi hứa tự động hóa đáng tin.
Rà soát rõ ranh giới bảo mật
Lần theo thao tác nhạy cảm từ trình duyệt đến kết quả lưu. Xác định nơi thiết lập danh tính, kiểm tra quyền, dữ liệu qua ranh giới tin cậy và nơi kiểm tra hợp lệ. Yêu cầu tác nhân thử mã tổ chức khác và giải thích vì sao máy chủ từ chối.
Giữ bí mật ngoài mã nguồn và gói công khai. Cấp quyền tích hợp hẹp và có cách thu hồi. Nếu có dịch vụ AI, quyết định thông tin được gửi, cách kiểm tra đầu ra và hành vi khi dịch vụ vắng mặt hoặc tạo nội dung không phù hợp.
Hướng dẫn phân quyền của OWASP là tài liệu tham khảo hữu ích. Áp dụng vào tuyến xử lý và bản ghi thực. Trích danh sách kiểm tra không phải bằng chứng ứng dụng thực thi đúng chính sách.
Yêu cầu tài liệu có thể bảo trì
Yêu cầu sơ đồ nhỏ, mô hình dữ liệu, bản ghi quyết định và luồng yêu cầu mẫu. Giữ gần mã và cập nhật khi lựa chọn quan trọng đổi. Tài liệu kiến trúc lớn được tạo tự động thành gánh nặng nếu mô tả tính năng không có hoặc hứa độ bền chưa thử.
Danh sách bất biến ngắn đặc biệt hữu ích: người dùng không đọc yêu cầu tổ chức khác; thử lại tạo yêu cầu không sinh bản thứ hai; thông báo lỗi không xóa yêu cầu đã lưu. Mỗi bất biến định hướng triển khai và kiểm thử.
Gắn tuyên bố kiến trúc với bằng chứng khi có thể. Kiểm thử tuyến xử lý hỗ trợ cách ly tổ chức; kiểm thử thử lại hỗ trợ thiết kế mã thao tác. Khi chưa có bằng chứng, ghi đó là ý định thiết kế còn cần kiểm chứng.
Biết khi nào cần xem lại quyết định
Đặt ngưỡng theo ràng buộc quan sát được. Xem lại thông báo khi không phục hồi lỗi trong mức dịch vụ đã hứa. Xem lại truy cập lưu trữ khi truy vấn đo được ảnh hưởng quy trình. Xem lại cấu trúc triển khai khi nhóm hoặc ranh giới phát hành gây khó phối hợp thật.
Tránh ngưỡng mơ hồ như “khi thành công”. Cũng đừng xem thiết kế đầu là vĩnh viễn. Kiến trúc tốt giúp thay đổi dự kiến dễ kiểm soát và vẫn chừa chỗ học sản phẩm thực cần gì.
Kết luận: dùng AI để làm rõ quyết định
AI hữu ích khi giúp tìm giả định ẩn, so sánh phương án đáng tin và giải thích hành vi lỗi. Kỹ sư vẫn chịu trách nhiệm chọn ranh giới và kiểm chứng hệ quả. Thiết kế gọn mà nhóm vận hành được thường giá trị hơn thiết kế rộng không ai tự tin sửa.
Xem lại lát cắt Chương 2, viết ba bất biến và một bản ghi quyết định. Chương 4 chuyển chúng thành chiến lược kiểm thử và phát hành MVP.
