Architecture change có rủi ro cao

Thay đổi topology, schema, deployment hoặc dependency có thể làm evidence cũ không còn áp dụng. Xác định capability cần reverify.

Những câu hỏi cần trả lời

  • Flow nào phụ thuộc thành phần đã đổi?
  • Scenario trước nào không còn áp dụng?
  • Cần verify gì trước khi tiếp tục triển khai?

Kết quả cần bảo vệ

Giữ critical capability khi topology, dữ liệu, deployment behavior hoặc dependency thay đổi.

Cách điều tra

Lần theo claim và dependency bị tác động. Xác định phép thử đại diện, điểm quan sát, triển khai an toàn, rollback và trách nhiệm rà soát.

Quyết định & kết quả

  • Bản đồ flow và claim bị tác động
  • Reverification plan tập trung
  • Quyết định rollout với giới hạn rõ ràng

Payment adapter mới thay đổi evidence boundary

Scenario giả định, không phải kết quả khách hàng.

Câu hỏi cần làm rõKết quả kiểm thử timeout và retry trước đây còn áp dụng sau khi đổi tích hợp thanh toán?

  1. Previous adapter verified
  2. Integration changes
  3. Affected claims reviewed
  4. Targeted reverification

Before the change

Tích hợp cũ giữ được kết quả thanh toán đã chọn trong bài thử timeout có phạm vi rõ ràng. Kết quả được giữ lại, nhưng không còn cập nhật cho đường đã đổi.

Evidence basis
Tested
Verification result
Verified
Freshness
Stale

After the change

Tích hợp mới có hành vi timeout và retry khác. Chưa thử tương tác với bước tạo đơn hàng.

Evidence basis
Unknown
Verification result
Unverified
Freshness
Unknown

Quyết định tiếp theo

Reverify timeout, retry và idempotency qua ranh giới thanh toán–đơn hàng trước khi dùng kết quả cũ hỗ trợ quyết định phát hành.

Phạm vi của ví dụ

Không còn cập nhật không có nghĩa là bị lỗi. Hành vi mới vẫn chưa verify; ví dụ không hàm ý nền tảng tự phát hiện thay đổi.

Tìm hiểu phương pháp đằng sau ví dụ

Cùng scenario được phân tích tiếp tại trang liên kết.

Chọn một critical flow.

Chia sẻ điều cần hoạt động đúng và câu hỏi cần trả lời. Hai bên thống nhất phạm vi trước khi triển khai.