Mediator là một mẫu thiết kế hệ thống giúp giảm thiểu sự phụ thuộc hỗn loạn giữa các đối tượng, bằng cách áp dụng biện pháp hạn chế giao tiếp trực tiếp giữa các đối tượng mà buộc chúng phải thông qua một đối tượng trung gian.
Ban đầu khi chưa biết đến khái niệm này mình có kiểu viết mã rất "hỗn loạn" trong cả Front-end lẫn Back-end. Các thành phần trong hệ thống đôi khi không hoạt động độc lập mà chúng còn tương tác với nhau, chính việc tương tác này gây ra nhiều khó khăn trong quá trình gỡ lỗi và bảo trì. Để mình lấy lần lượt từng ví dụ cho mọi người dễ hình dung.
Đầu tiên là ở phía máy chủ, cộng với kiến trúc microservice mà hệ thống có nhiều mảnh ghép hoạt động trong một phạm vi nhất định. Giả sử bạn có 3 khối dịch vụ là A, B, và C giao tiếp với nhau thông qua HTTP. A cần B thì A gọi đến B. A cần C thì A gọi đến C. Tương tự B gọi C... Nhưng đó mới chỉ dừng lại ở con số ví dụ là 3, nếu bạn có 6, 9, 12... khối như vậy thì chắc hẳn việc giao tiếp chồng chéo đến mức khó mà tưởng tượng ra được. Vì vậy để điều phối dễ hơn, chúng ta nên lập ra một người hoà giải, gọi là M. Các cuộc gọi giao tiếp phải thông qua M, khi đó M có thể điều phối, ghi nhật ký để cho quá trình gỡ lỗi sau này trở nên dễ dàng hơn.

Ở phía giao diện, nơi bạn có nhiều nút bấm, khung nhập văn bản, hộp thoại cảnh báo... Nếu ứng dụng đơn giản thì không nói đến vì việc tương tác 1-1 không gặp nhiều khó khăn là mấy, thậm chí nó còn đẩy nhanh quá trình viết mã. Nhưng một khi các nút nhiều hơn, khung nhập nhiều hơn và logic giữa chúng trở nên rắc rối hơn vì việc tương tác 1-1 lại tỏ ra kém hiệu quả, thay vào đó hãy thử áp dụng mẫu thiết kế Mediator để điều phối chúng

Một nơi mà mình áp dụng mẫu này rất thành công là trong ứng dụng OpenNotas. Nơi có nhiều thành phần tham gia tương tác với nhau. Nhưng thay vì để chúng tương tác trực tiếp thì phải thông qua một người hoà giải. Bạn đọc có thể tham khảo mã nguồn tại tonghoai/opennotas.
Tài liệu tham khảo: