Cái tên trên whiteboard nhìn rất ổn. Có API layer, domain layer, integration layer, và một ô nhỏ gọi là policy. Mọi người hiểu các từ đó trong vài phút. Rồi use case thật đầu tiên xuất hiện, và team âm thầm disagree về chỗ validation nên sống ở đâu.
Đây là khoảnh khắc rất thường gặp trong architecture work. Ta hay tin rằng boundary đã rõ vì nó có tên. Nhưng tên gọi có thể tạo ra sự bình tĩnh giả. Repository, service, usecase, adapter, policy, gateway: mỗi từ mang theo một lịch sử local. Hai engineer có thể dùng cùng một tên mà vẫn tưởng tượng responsibility khác nhau.
Example làm boundary khó bị giả vờ rõ. Thay vì nói policy layer quyết định eligibility, hãy viết một input và decision mong đợi. Thay vì nói adapter che provider, hãy đưa một provider error và cách domain nên nhìn thấy nó. Thay vì nói usecase orchestrate, hãy trace một request từ handler đến repository rồi quay lại.
Một example tốt làm ownership hiện ra. Nếu phone number cần normalize, example buộc team quyết định việc đó thuộc handler, usecase, domain hay repository. Câu trả lời có thể đơn giản, nhưng viết example ngăn decision ở lại dưới dạng tribal knowledge. Contributor sau này có thể theo behavior thay vì đoán từ tên folder.
Example cũng cho thấy khi boundary đang quá tham vọng. Diagram có thể sạch trong khi các example cứ băng qua line. Nếu case quan trọng nào cũng bắt domain biết provider detail, có lẽ adapter contract quá mỏng. Nếu usecase nào cũng duplicate eligibility logic, có lẽ policy cần một chỗ explicit hơn.
Điểm chính không phải thay diagram. Diagram giúp mọi người thấy shape nhanh. Nhưng diagram không có example giống bản đồ không có khoảng cách. Nó nói các điểm nằm ở đâu, không nói effort giữa chúng. Vài flow cụ thể làm bản đồ trung thực hơn.
Khi team lớn lên, example trở thành một sự tử tế. Teammate mới không cần thừa hưởng mọi cuộc tranh luận tạo ra architecture. Họ cần đủ behavior visible để hiểu boundary tồn tại vì sao và thế nào là phá vỡ nó. Một example nhỏ có thể tiết kiệm nhiều review comment sau này.
Trước khi đặt tên thêm một boundary, hãy thử viết ba example nên đi qua nó và ba example không nên đi qua. Nếu các example khó đặt chỗ, cái tên vẫn chưa đủ. Boundary nào trong system hiện tại của bạn sẽ rõ hơn nếu team viết một example cụ thể bên cạnh nó?