Основное различие между решениями заключается в том, как вы хотите различать разные форматы данных и где должна лежать эта ответственность. Опираясь на одну очередь на формат, вы связываете формат с компонентом инфраструктуры. Напротив, используя нормализатор EIP, вы различаете форматы данных на основе содержимого сообщения на уровне приложения. Основным недостатком первого решения является то, что оно не может хорошо и быстро масштабироваться, так как вам необходимо изменить как инфраструктуру, так и уровни приложений. Это также означает, что большое количество форматов требует одинаково большого количества очередей (здесь могут быть проблемы с использованием и оптимизацией ресурсов).
Я пытался придерживаться строгого намерения самого шаблона и проблему, которую он пытается решить, также учитывая, что чаще всего перевод не требует сложной обработки. В любом случае, иногда все не так просто, и вы можете выбрать выделенные очереди также для лучшего распределения нагрузки, например, когда один производитель имеет большой объем или когда логика и вычисления перевода не сопоставимы между форматами данных. В других случаях, особенно при интеграции вашего собственного мультитенантного приложения с системами других клиентов, у вас могут быть маршруты, строго отделенные друг от друга, чтобы не мешать ограниченному контексту мешать друг другу.
При этом и Подводя итог, это всегда зависит :) Как правило, если вы являетесь владельцем инфраструктуры промежуточного программного обеспечения, а число форматов очень мало или не должно часто меняться или расти, вероятно, оба решения верны, хотя я бы всегда go со вторым, если мне не нужно масштабировать в зависимости от рабочей нагрузки / клиентов и если содержание сообщения позволяет мне.
Надеюсь, я помог.