Cây bút vừa vẽ vài ô vuông và mũi tên lên bảng thì một câu hỏi vang lên từ góc phòng: quý sau quy tắc đổi, ai sẽ là người chịu trách nhiệm sửa phần này? Buổi trao đổi vốn bắt đầu bằng chuyện chọn framework. Chỉ một câu ấy đã kéo nó về vấn đề khó hơn nhiều: ranh giới nằm ở đâu.
Bắt đầu kiến trúc bằng công cụ rất hấp dẫn vì mọi thứ trông cụ thể. Queue có tên, database có trang giới thiệu, framework có ví dụ và benchmark. Ranh giới khiến người ta khó chịu hơn: nó buộc cả đội nói rõ công việc thay đổi ra sao, quyết định thuộc về ai và bên nào sẽ gánh chi phí về lâu dài.
Một đường kẻ trên sơ đồ thực chất là lời hứa về sự thay đổi. Nếu chính sách thanh toán đổi mỗi tuần còn quy tắc danh mục sản phẩm đổi chậm, gom cả hai vào một module có thể tiện hôm nay nhưng đắt mai sau. Nếu bộ phận hỗ trợ khách hàng cần cách đọc dữ liệu khác quy trình checkout, bắt cả hai đi qua cùng một mô hình có thể sinh ra ma sát mà không framework nào che nổi.
Vì vậy, trước khi bàn công nghệ, hãy làm rõ ba chuyện. Ai hiểu quy tắc đủ sâu để thay đổi nó mà không phải xin ý kiến năm nơi? Những dữ kiện nào bắt buộc nhất quán cùng lúc, và dữ kiện nào có thể đến muộn một chút mà vẫn an toàn? Khi hai đội nói cùng một từ, họ có thật sự nói cùng một nghĩa không? Quyền sở hữu, tính nhất quán và ngôn ngữ chung thường phơi ra ranh giới thật nhanh hơn tên một sản phẩm.
Những câu hỏi ấy không sôi nổi bằng tranh luận công nghệ, nhưng thường tiết kiệm nhiều tháng sửa sai. Tách service chỉ vì microservices nghe hiện đại có thể tạo thêm một network call bao quanh sự mơ hồ. Dồn mọi thứ vào shared library để tránh lặp code có thể biến nó thành ngăn kéo chung, nơi đội nào cũng nhét giấy tờ không liên quan. Chọn database trước khi hiểu quy tắc nhất quán có thể đổi một luồng nghiệp vụ thành hàng loạt buổi họp phục hồi dữ liệu.
Không phải công cụ không quan trọng. Chúng rất quan trọng sau khi hình dạng bài toán đã lộ ra. Queue hợp lý khi công việc có thể chạy bất đồng bộ. Modular monolith thường nhẹ nhàng hơn với đội nhỏ và miền nghiệp vụ còn đang được khám phá. Một service riêng đáng trả chi phí vận hành khi quyền sở hữu, nhịp triển khai và áp lực scaling thật sự khác nhau.
Tôi thích những cuộc bàn kiến trúc chịu hoãn phán quyết về công cụ thêm một chút. Không phải hoãn mãi, chỉ đủ lâu để ghi ra thứ gì thay đổi cùng nhau, hỏng cùng nhau, cần được test cùng nhau và có thể giao cho một nhóm tự chịu trách nhiệm. Khoảng dừng ngắn ấy thường biến một lựa chọn công nghệ ồn ào thành một quyết định thiết kế có căn cứ.
Ranh giới tốt nhất hiếm khi là đường kẻ đẹp nhất trên bảng. Nó là đường giúp thay đổi kế tiếp được thực hiện bởi người ở gần hiểu biết nhất, với phạm vi ảnh hưởng nhỏ vừa đủ. Công cụ có thể thay; một ranh giới đặt sai thường bắt nhiều người trả phí trong từng lần thay đổi về sau.