.net реализация связи между совокупными корнями в другом ограниченном контексте

Это первый раз, когда я применяю концепции DDD к реальной проблеме.

Я начал только с 1 ограниченного контекста, так как проект относительно небольшой. Однако я обнаружил, что классы почти идентичны, то есть очень похожие имена, очень похожие свойства, но другое поведение. Я начинаю думать, что они на самом деле принадлежат к разным ограниченным контекстам, поскольку сущности одинаковы и просто имеют разное значение в другом контексте. Это подтверждается тем фактом, что в приложении есть две совершенно разные группы пользователей.

Я немного почитал о том, как два объекта в разном ограниченном контексте могут общаться друг с другом. Я думаю, что я понимаю концепцию... но понятия не имею, как ее реализовать? Есть ли где-нибудь пример .net? т. е. совокупный корень в одном ограниченном контексте, публикующий событие в совокупном корне в другом ограниченном контексте? а также совокупный корень, вызывающий совокупный корень в другом ограниченном контексте.

И должен ли каждый ограниченный контекст иметь свой собственный сервисный уровень? репозиторий и уровень данных?


.net design-patterns domain-driven-design aggregateroot bounded-contexts
person Cool Breeze    schedule 27.11.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Это может помочь, это цитата из книги «Внедрение дизайна, управляемого предметной областью» Вона Вернона.

«Возможно, наиболее распространенное использование событий предметной области — это когда агрегат создает событие и публикует его. Издатель находится в модуле модели, но не моделирует какой-либо аспект. Скорее, он предоставляет простой сервис для агрегатов, которые необходимо уведомлять подписчиков о событиях».

События публикуются с помощью службы, и реализация обработчика зависит от приемлемого времени, в течение которого остальная часть модели в конечном итоге будет приведена в соответствие. С Моими особыми требованиями допустима небольшая задержка по времени. События моего домена публикуются в очереди с помощью MSMQ, затем во внешнем процессе я читаю из очереди и выполняю работу. Такой дизайн позволяет мне перенести эту работу на внешний хост и освободить IIS. Я использую тот же механизм для сохранения изменений в хранилище. Когда транзакция на моем агрегате завершена, я публикую зафиксированное событие в MSMQ и получаю 2 очереди в многоадресной рассылке. Одна очередь для обработки дополнительной работы, а другая для сохранения.

Если вы еще не читали ее, я очень рекомендую эту книгу. Я уверен, что мой дизайн вызовет некоторую критику, но ваша реализация будет зависеть от ваших требований и от того, насколько вам удобно использовать конечную согласованность.

Надеюсь, это поможет, и если вы решите использовать MSMQ, вот ссылка для начала. http://msdn.microsoft.com/en-us/library/aa480407.aspx

Вот моя реализация издателя событий предметной области.

public class DomainEventPublisher
{
    string DomaineEventMessageQueue = @"FormatName:MULTICAST=234.1.1.1:8001";

    public void PublishEvent(DomainEvent domainEvent, string correlationId)
    {
        MessageQueue eventQueue;

        eventQueue = new MessageQueue(DomaineEventMessageQueue);

        Message message = DomainEventMessage.CreateDomainEventMessage(domainEvent);

        message.CorrelationId = correlationId;

        eventQueue.Send(message);
    }

}
person Casey    schedule 27.11.2014

arrow_upward
2
arrow_downward

Итак, у меня есть 4 возможности для вас.

  1. Пересмотрите свою модель предметной области: тот факт, что вам необходимо обмениваться данными между агрегатами, может указывать на проблему с моделью. Ключевым моментом здесь является то, что все в ограниченном контексте остается согласованным, но между агрегатами нет никаких гарантий.

  2. Используйте диспетчер процессов (или SAGA): аналогично ответу выше, вы можете реагировать на события предметной области и координировать межагрегатную коммуникацию от диспетчера процессов.

  3. Внедрение службы: будьте осторожны с этим, так как вы хотите установить премиум-зависимость без или с небольшим количеством зависимостей в своем домене. Сказав, что это все еще может быть правильным или, если не самым прагматичным способом решения проблемы.

  4. Измените свою точку зрения: у вас уже есть информация из другого агрегата, прежде чем взаимодействовать? Если да, то можно ли передать это с помощью любой команды, устраняющей необходимость в общении?

Я подробно расскажу об этом в своем блоге. Если вы сочтете это полезным, вы можете перейти к нему отсюда: 4 секрета межагрегатной коммуникации в системе, основанной на событиях

person Codescribler    schedule 03.12.2014