Является ли обычной практикой наличие общей и выделенной сборки или библиотеки для сообщений в распределенной системе?

Я рассказываю о некоторых концепциях, лежащих в основе дизайна, основанного на распределенных доменах, и я создаю доказательство концепции. У меня есть три решения C#, которые несут определенную ответственность в рамках всей системы.

Решения, которые у меня есть:

  • Модель записи (получает команды от клиента, создает и отправляет события)
  • Модель чтения (получает события из модели записи, создает базу данных и предоставляет услуги DTO клиенту, потенциально может быть двумя отдельными решениями)
  • Клиент (вызывает службы для получения необходимых данных и отправляет команды модели записи)

Все три решения используют обмен сообщениями (команды, события) через служебную шину. (Массовый транспорт в моем случае).

Мой главный вопрос: является ли обычной практикой создание сборки с сообщениями и наличие ссылки на эту сборку в каждом решении?

Дополнительный балл: Есть ли что-то, что я делаю, что кажется странным или проблематичным в этом POC? Любая дополнительная информация, о которой я должен знать при создании такого типа системы?


cqrs masstransit distributed-system .net-assembly domain-driven-design
person Landon Poch    schedule 26.10.2012    source источник
comment
Я склонен делиться контрактом, а не кодом (ни скомпилированным, ни в исходной форме). Это зависит от того, насколько закрыта система.   -  person Yves Reynhout    schedule 28.10.2012

Ответы (1)


arrow_upward
4
arrow_downward

Является ли обычной практикой создание сборки с сообщениями и наличие ссылки на эту сборку в каждом решении?

Да. Это обычная практика для систем обмена сообщениями в целом. Например, этот подход используется во многих образцах NServiceBus. Думайте об этой сборке как о вашем контракте. В системах, построенных на разных платформах, это представление будет иметь форму схемы XSD или какого-либо другого механизма определения схемы.

Есть ли что-то, что я делаю, что кажется странным или проблематичным в этом POC? Любая дополнительная информация, о которой я должен знать при создании такого типа системы?

Кажется, пока все хорошо подходит для CQRS. Справедливости ради, я должен упомянуть, что легко увлечься CQRS как серебряной пулей и структурировать системы вокруг него. Часто бывает мудрым решением полностью отказаться от CQRS. Сосредоточьтесь на сфере бизнеса и используйте CQRS как архитектурный стиль для реализации вашей системы, а не для управления ее моделью.

person eulerfx    schedule 26.10.2012
comment
Спасибо за ответ. Хороший комментарий о том, как увлечься. Я согласен с тем, что многие шаблоны, связанные с CQRS/DDDD, могут легко сбить вас с пути проектирования, который является излишним. На данный момент это просто POC, поэтому я стараюсь изо всех сил ради чистой выгоды обучения. Я считаю, что игра с идеями таким образом кладет инструменты в пояс инструментов, а затем я могу решить, какие из них мне действительно нужны, чтобы вытащить и использовать в реальном проекте. - person Landon Poch; 26.10.2012
comment
Добавлю, что я использовал общую сборку для контрактов сообщений в ряде проектов MassTransit. То, что сказал @eulerfx, полностью соответствует моему опыту. - person Travis; 27.10.2012
comment
Кроме того, рассматривая использование интерфейсов, а не классов в сборке сообщений, позвольте производителю сообщения реализовать интерфейс как частный вложенный класс — просто чтобы сохранить четкое разделение между самим контрактом сообщения и реализацией. - person Chris Patterson; 30.10.2012