Интеграция с ограниченным контекстом DDD

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

Допустим, один контекст - это Document Core Bounded Context (BC) и имеет объект Document с Author. Использование IdentityAccessContext BC, как в Реализация книги DDD, которая разделяет пользователей, группы и роли в их собственном контексте, имеет смысл.

Проблема возникает при рассмотрении возможности получения списка из 100+ документов.

Допустим, у ядра документа BC есть собственная сущность, которая обозначает автора документа.

public class Author
{
    long Id; // Same as UserId
    long Document;  
}

И тогда у удостоверения BC есть Пользователь с соответствующей информацией.

public class User
{
    long Id;
    string FullName;
}

При получении списка документов, как информация из IdentityAccess BC должна быть извлечена в / с помощью автора документа < / em> для отображения (например, полное имя)?

Кажется, есть пара альтернатив:

  1. Может быть, уровень защиты от коррупции, который извлекает данные из обеих таблиц?
  2. Дублировать полное имя пользователя в двух BC?

Ни то, ни другое не кажется правильным, поскольку №1 требует объединения данных (на каком-то уровне) из 2 BC, в то время как № 2 требует потенциально обновления нескольких BC при изменении имени пользователя.

Что с этим можно сделать? (Использование C #, MVC, NHibernate, если это важно) Четкая выборка списка объектов, а затем выборка, например. Имя автора и дополнительные данные позже нереально.

Однако при рассмотрении интеграции BC, учитывая 3 варианта, упомянутые в книге RPC, Domain Events, and RESTful service integration, по крайней мере, последние 2 не имеют смысла в этом случае. где приложение является MVC, и оно напрямую использует 2 BC как библиотеки классов, и они оба используют одну и ту же базу данных. Обновление информации о пользователях может быть выполнено непосредственно из MVC через службы приложения Identity BC's. База данных и BC могут быть изменены по мере необходимости.


c# asp.net-mvc domain-driven-design bounded-contexts
person lko    schedule 14.11.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вместо того, чтобы интегрировать эти ограниченные контексты, вы, вероятно, захотите их составить. Взгляните на соответствующий раздел в главе «Применение» в книге по внедрению DDD.

Один из подходов - создать службу приложения, которая обращается к обоим ограниченным контекстам и создает документ DTO, содержащий информацию из обоих BC.

Вы даже можете пойти дальше и создать для него третий ограниченный контекст и использовать хорошо известные методы интеграции BC, чтобы синхронизировать этот новый BC (обмен сообщениями, ночная пакетная обработка и т. Д.). Как указывает Вон Вернон в своей книге, это, вероятно, приведет к модели анемичной области в этой новой Британской Колумбии.

person fstuijt    schedule 27.11.2013

arrow_upward
1
arrow_downward

Некоторые решения, которые могут вас заинтересовать:

A. Использование избыточных атрибутов в ограниченном контексте документа. нравиться

public class Author {
    long Id; // Same as UserId
    string fullname://redundant
    long Document;  
}

Но этот не является гибким, и модель должна измениться, если изменится требование запроса.

Б. Модель предметной области плохо справляется с запросами. Если вы знакомы с CQRS, лучшим решением будет создание отдельного компонента запроса.

person Yugang Zhou    schedule 28.11.2013