.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

Това може да помогне, това е цитат от Implementing Domain Driven Design от Vaughn Vernon.

„Може би най-честата употреба на събития в домейна е, когато агрегат създава събитие и го публикува. Издателят се намира в модул на модела, но не моделира някои аспекти. По-скоро предоставя проста услуга на агрегатите, които трябва да уведомите абонатите за събитията."

Събитията се публикуват с помощта на услуга и внедряването на манипулатора зависи от приемливото време за останалата част от модела, за да бъде в крайна сметка приведена в съответствие. С моите специални изисквания е приемливо за малко забавяне във времето. Моите събития в домейна се публикуват в опашка с помощта на 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