Buổi rà soát thiết kế cứ mắc ở câu hỏi nếu mai này mọi thứ đều đổi thì sao. Rồi có người hỏi lại: phần nào đã thật sự đổi đến ba lần? Cả phòng chậm xuống. Mọi người cùng chỉ được vài chỗ rất cụ thể: một quy tắc riêng của khách hàng, một dạng báo cáo, phản hồi từ nhà cung cấp và một bước trong quy trình cứ phải sửa đi sửa lại.
Đội làm phần mềm thường trả khá đắt cho sự linh hoạt còn nằm trong tưởng tượng. Ta thêm lớp trừu tượng vì một phiên bản tương lai có thể cần, mở sẵn điểm mở rộng chưa ai dùng, hoặc tách mô-đun trước khi có áp lực thật. Ý định không sai: ai cũng muốn hệ thống chịu được thay đổi. Nhưng thiết kế sẽ nặng nề nếu phải che chắn trước mọi kiểu thời tiết, trong khi cơn mưa đang tới lại ở ngay trước mắt.
Câu hỏi hữu ích hơn là: mình đã nhìn thấy loại thay đổi nào? Quy tắc tính giá có thể đổi thường xuyên trong khi khâu thu tiền khá ổn định. Dữ liệu từ các đối tác có thể mỗi nơi một kiểu, còn contract đơn hàng bên trong cần giữ vững. Câu chữ trên giao diện có thể đổi hàng tuần, nhưng state machine hiếm khi động tới. Dấu vết ấy cho biết chỗ nào đáng bỏ công làm linh hoạt.
Như vậy không có nghĩa là mặc kệ tương lai. Chỉ là ta để bằng chứng sắp thứ tự cho những khả năng tương lai. Một khu vực đã thay đổi lặp lại thì nên có đường biên để hấp thụ thay đổi đó. Một nỗi lo mới chỉ là giả định thì cứ ghi lại và chờ thêm tín hiệu. Một dòng ghi chú rẻ hơn nhiều so với một lớp trừu tượng mà những người đến sau phải gánh mãi.
Sự đơn giản cũng cần được bảo vệ theo cách này. Một cách làm đơn giản không hề ngây thơ nếu nó nằm ở phần ổn định. Ngược lại, nhiều lớp linh hoạt chưa chắc đã trưởng thành nếu chúng chỉ phủ lên sự mơ hồ. Thiết kế chín chắn là thiết kế vừa với áp lực thật, không phải nơi nào cũng trừu tượng như nhau.
Chẳng hạn, khi ba nhà cung cấp dùng ba bộ tên trạng thái khác nhau, một lớp adapter để quy đổi thường đáng giá. Nếu mới có một nhà cung cấp và chưa hề có kế hoạch thêm bên thứ hai, adapter vẫn có thể giúp ranh giới rõ hơn, nhưng nên nhỏ gọn. Quyết định cần đi theo đường thay đổi đang hiện ra, chứ không đi theo một khẩu hiệu về clean architecture.
Đường thay đổi ấy cũng không đứng yên. Phần từng ổn định có thể bắt đầu biến động; điều từng khiến cả đội lo có thể hóa ra chẳng còn quan trọng. Kiến trúc vì thế không phải một lần đặt cược cho đúng, mà là nhiều lần chỉnh lại khi bằng chứng rõ hơn. Mục tiêu không phải đoán trúng mọi thứ, mà là giữ cho hệ thống dễ hiểu trong lúc thực tế dần lên tiếng.
Trước khi thêm một lớp mới, thử chỉ ra nó đang bảo vệ hệ thống khỏi thay đổi nào và thay đổi ấy đã xuất hiện ở đâu. Nếu chưa chỉ ra được, có lẽ lúc này một ghi chú nhỏ đã là đủ. Sự linh hoạt nên được mua bằng bằng chứng, không phải bằng nỗi sợ về một tương lai chưa ai nhìn thấy.