Ого, будет сложно дать ответ более тщательный или более достоверный, чем MSDN, с которым вы связаны, поэтому давайте перейдем к более краткому.
Шина сообщений связана с связью . Это даже не требует, чтобы сообщение было доставлено, является командой или нет. Это также не волнует, какова полезная нагрузка. Это "тип агностика". Основная задача шины сообщений - просто отслеживать, кто должен получать каждое сообщение (паб / суб). Преимущество этой модели в том, что она будет поддерживать расширение в будущем, для которого у вас пока нет спецификаций. Вы можете добавить новый тип сообщения в будущем, и эта модель будет рада доставить его. Шина сообщений, скорее всего, будет распространяться за пределами вашего приложения и, возможно, даже за пределами вашей машины (скажем, распределена между кластером из 10 серверов).
Модель обработчика команд связана с отделением действий от выполнения команды. Традиционно (по крайней мере на языках, которые я использую) команды были очень тесно связаны с элементами управления пользовательского интерфейса, их событиями и потоком пользовательского интерфейса. С этой старой моделью также было трудно настроить или расширить диапазон доступных команд в вашем приложении (скажем, с расширением DLL). Модель обработчика команд разделяет эти проблемы пользовательского интерфейса и выполнения команд. Теперь у вас есть возможность легко добавлять дополнительные обработчики команд и выполнять команды без события пользовательского интерфейса ( Возможность модульного тестирования ). Это делает код более понятным, модульным и тестируемым. Обработчик команд, скорее всего, будет частью вашего приложения внутри. Любые расширения вашей коллекции команд могут повлиять на одно приложение, а не на несколько приложений.
Посредник сообщений / команд занимается подключением несовместимых или по-разному сконструированных независимых систем. Это тот случай использования, когда вы хотите, чтобы одно приложение взаимодействовало с другим, и у вас нет исходного кода для одного или обоих приложений. Таким образом, вы создаете брокера, который получает информацию с одной стороны и предоставляет эту информацию с другой стороны с учетом любых преобразований, необходимых для взаимодействия этих двух приложений. Примером на MSDN является веб-сайт электронной коммерции, которому, возможно, потребуется поговорить с платежным процессором, транспортной компанией и системой бухгалтерского учета. У вас может не быть возможности изменить исходный код для любого из этих приложений (включая систему электронной коммерции). Возможно, для системы электронной торговли требуется интерфейс IExamplePaymentGateway, а вашему провайдеру платежей необходим интерфейс IDifferentPaymentAPI. Может быть, один API реализован в XML, а другой в JSON? Каковы бы ни были различия, ваш брокер несет ответственность за возможность подключения.
Как видите, все они связаны тем или иным способом. Границы между ними могут быть размытыми, и вы даже можете использовать комбинацию из нескольких из этих шаблонов для достижения вашего конкретного случая использования.
Хотя я никогда не использовал NServiceBus, большинство библиотек этого типа просто пытаются объединить абстрактные / академические модели в более конкретные языковые реализации. Иногда это экономит ваше время, иногда вы застряли с плохой реализацией от неизвестного участника с открытым исходным кодом. Вам необходимо оценить собственный сценарий использования и пригодность инструментов, доступных на выбранном вами языке разработки.