Whiteboard bắt đầu hữu ích trước khi tên tool xuất hiện. Trên đó chỉ có vài cái box, một vài mũi tên, và một câu hỏi rất nhỏ từ góc phòng: ai sẽ sở hữu phần thay đổi này khi rule đổi vào quý sau? Cuộc nói chuyện ban đầu xoay quanh việc chọn framework, nhưng cái bảng đang dần nói rằng quyết định khó hơn không nằm ở syntax kỹ thuật. Nó nằm ở boundary.
Rất dễ bắt đầu architecture bằng tool vì tool tạo cảm giác cụ thể. Queue có tên. Database có trang vendor. Framework có example và benchmark. Boundary khó hơn vì nó bắt con người mô tả cách công việc thay đổi, nơi decision sống, và team nào sẽ mang chi phí dài hạn.
Boundary không chỉ là một đường trên diagram. Nó là một lời hứa về change. Nếu billing policy đổi mỗi tuần nhưng rule của product catalog đổi chậm hơn nhiều, đặt chúng trong cùng một module có thể tiện hôm nay và đắt về sau. Nếu customer support cần read model khác checkout, ép cả hai đi qua cùng một shape có thể tạo friction mà không framework nào che được.
Câu hỏi boundary đầu tiên là ownership. Ai hiểu rule đủ sâu để thay đổi nó mà không phải xin năm người khác cho phép? Câu hỏi thứ hai là data. Fact nào cần consistent cùng nhau, và fact nào có thể đến chậm một chút mà không làm mất niềm tin? Câu hỏi thứ ba là language. Hai team có dùng cùng một từ để nói cùng một nghĩa không, hay họ đang vô tình dùng chung một từ cho hai thực tế khác nhau?
Những câu hỏi này yên lặng hơn một cuộc tranh luận công nghệ, nhưng thường tiết kiệm nhiều thời gian hơn. Một service boundary được chọn chỉ vì microservices nghe hiện đại có thể trở thành một network call bao quanh sự mơ hồ. Một shared library được tạo chỉ để tránh duplicate có thể thành cái ngăn kéo nơi mọi team giấu giấy tờ không liên quan. Một quyết định database trước khi hiểu consistency rule có thể biến một business workflow thành nhiều buổi họp sửa lỗi.
Điều này không có nghĩa tool không quan trọng. Tool rất quan trọng sau khi shape của vấn đề đã hiện rõ. Queue có thể rất đúng khi work có thể xử lý async. Modular monolith có thể tử tế hơn khi team nhỏ và domain còn đang học chính nó. Một service riêng có thể xứng đáng với operational cost khi ownership, deployment pace và scaling pressure thật sự khác nhau.
Tôi thích những cuộc trò chuyện architecture trì hoãn verdict về tool thêm một chút. Không phải mãi mãi, chỉ đủ lâu để viết xuống thứ gì thay đổi cùng nhau, thứ gì fail cùng nhau, thứ gì cần test cùng nhau, và thứ gì có thể được sở hữu độc lập. Khoảng dừng đó thường biến một lựa chọn công nghệ ồn ào thành một design decision bình tĩnh hơn.
Boundary quan trọng nhất thường không phải boundary đẹp nhất. Nó là boundary giúp change tiếp theo được thực hiện bởi người gần knowledge nhất, với blast radius nhỏ nhất hợp lý. Nếu team bạn từng tiếc vì chọn tool trước khi gọi tên boundary, câu chuyện đó rất đáng mang lại vào buổi design review tiếp theo.