Trong một buổi architecture review, có người vẽ một abstraction mới lên bảng. Nó trông gọn và có vẻ support được nhiều case tương lai. Nó cũng làm feature hiện tại khó giải thích hơn. Sau vài phút, câu hỏi hữu ích nhất không phải là design có clever không. Câu hỏi là boundary này có làm thay đổi tiếp theo nhàm chán hơn không.
Những boundary tốt nhất trong codebase thường gần như hơi chán. Chúng không gây ấn tượng bằng tên phức tạp. Chúng làm rõ rule nằm ở đâu, ai có thể đổi nó, và test nào nên fail nếu rule đó bị phá.
Một boundary hữu ích khi nó biến một decision thành chuyện local. Nếu pricing rule đổi, thay đổi đó không nên bắt team đọc cả notification sender, page layout và analytics mapper. Nếu authentication đổi, phần lớn product code không nên phải học một protocol mới. Boundary cho teammate tương lai một căn phòng nhỏ hơn để tìm.
Boundary nhàm chán cũng tạo ra những cuộc nói chuyện nhàm chán theo nghĩa tốt. Thay vì tranh luận taste mỗi lần, team có thể hỏi: phần này thuộc domain, adapter, use case hay presentation layer? Vocabulary không giải quyết mọi vấn đề, nhưng nó giảm chi phí bắt đầu conversation.
Điểm nguy hiểm là việc tạo boundary có thể trở thành trang trí. Một folder, interface hoặc service name mới không tự động tạo clarity. Đôi khi nó chỉ chuyển confusion sang một nơi có vẻ chính thức hơn. Bài test là boundary đó có làm team sửa behavior an toàn hơn không.
Tôi thích những boundary bảo vệ ownership. Code nên cho thấy phần nào của hệ thống sở hữu sự thật, phần nào translate từ thế giới bên ngoài, và phần nào chỉ display kết quả. Khi các responsibility này mờ đi, bug bắt đầu đi xa hơn mức cần thiết.
Chủ động chọn boundary nhàm chán nghĩa là có thể giải thích thứ gì được phép đi qua nó. Data có thể đi qua. Intent có thể đi qua. Framework detail có thể không cần đi qua. Shortcut có thể ổn cho spike, nhưng production code không nên bắt mọi người đọc sau này trả giá cho shortcut đó.
Lần tới khi một abstraction trông ấn tượng, hãy dừng đủ lâu để hỏi nó làm ngày mai dễ hơn ở đâu. Nếu nó giảm coordination, thu hẹp test surface và cho người tiếp theo một chỗ rõ ràng để làm, boring không phải điểm yếu. Đó là design đang làm đúng việc của nó.