Contract đó trông rất đầy đủ, và đó lại là một phần của vấn đề. Nó liệt kê mọi field có thể có người cần, vài optional shape, và vài value mà meaning phụ thuộc vào data đến từ đâu. Nó rộng rãi, nhưng khó tin. Cải thiện hữu ích đầu tiên không phải thêm field nữa. Đó là làm lời hứa nhỏ lại.
Data contract không phải nơi để cất hy vọng. Nó là shared promise giữa producer và consumer. Khi promise quá rộng, mỗi người bắt đầu phụ thuộc vào một góc khác nhau của nó, và không ai chắc phần nào thật sự stable.
Contract nhỏ dễ tin hơn vì dễ gọi tên hơn. Field này nghĩa là điều này. Value này luôn có mặt. Timestamp này dùng clock này. Identifier này thuộc owner này. Ngôn ngữ trở nên boring, và đó là dấu hiệu tốt.
Contract nhỏ cũng làm change visible hơn. Nếu một consumer mới cần thêm data, team có thể decide contract có nên lớn lên không, một read model riêng có tốt hơn không, hay consumer đó đang với tay qua boundary không nên vượt.
Ngược lại là all-purpose payload. Ban đầu nó tiện vì không ai cần request change. Về sau, producer sợ remove bất cứ thứ gì, còn consumer âm thầm phụ thuộc vào behavior chưa từng được review.
Testing là pressure test hữu ích. Nếu contract quá mơ hồ để test rõ, nó có lẽ cũng quá mơ hồ để dựa vào. Contract tốt nên có example, validation và failure case mà teammate tương lai chạy được mà không cần biết toàn bộ lịch sử.
Versioning cũng bớt kịch tính khi contract nhỏ. Promise hẹp dễ giữ compatible hơn. Promise rộng tạo accidental API surface area, và surface area vô tình thì già đi rất tệ.
Trước khi thêm field tiếp theo, hãy hỏi contract còn đủ nhỏ để giải thích không. Nếu team gọi được owner của nó, test được meaning của nó, và mô tả được ai đang depend vào nó, contract không chỉ là data đi qua. Nó là architecture đang làm việc âm thầm.