Самодостаточный дизайн не предписывает такие шаблоны или рекомендации.Но он предписывает, что вы проектируете вокруг своего домена , а не вокруг деталей инфраструктуры, таких как брокеры, очереди и т. Д.
При этом;и предположим, что вы выполняете ООП, обработка ваших доменных объектов как граждан первого класса, скорее всего, будет означать, что вы полностью отделите свой домен от своей инфраструктуры и, таким образом, предложите общие шаблоны, которые хороши в этом, такие как гексагональная архитектура.
Даже в этом случае DDD также не предписывает особый подход к интеграции;Тот факт, что вы спрашиваете об очередях, указывает на то, что вы рассматриваете Асинхронная интеграция .В этом нет ничего плохого, но это всегда окупается решениями архитектуры deffer .Особенно, если вы «собираетесь» открыть этот домен через DDD.Попробуйте начать с простого , слабо связанного, но сначала монолита , вы можете обнаружить, что вам вообще не нужны очереди.
Учитывая все вышеизложенное, в сценарии асинхронной интеграции с RabbitMQ принято использовать шаблон pub-sub .Все соответствующие события публикуются на один обмен без учета конкретного потребителя.Потребители устанавливают свои собственные очереди и привязки так, как им требуется, поэтому не существует единой формулы, которая работает:
- Одна очередь на тип события на одного потребителя
- Одна очередь на потребителя с несколькими привязкамидля типов событий или шаблонов тем
- Очереди, общие для пользовательских экземпляров для балансировки нагрузки
- ... и многие их комбинации.