Мы создали приложение для планирования научной программы конференций, включая залы, сессии, лекции (устные или постерные доклады), спикеров, председателей и т. д. (планирование программы контекст).
Одной из важных частей являются научные статьи с указанием их авторов из представленных статей, которые также могут привести к лекциям или стендовым докладам.
Контекст управления бумагой — это отдельный ограниченный контекст, который использует внешний API для синхронизации данных между сторонними инструментами. Он действует как уровень защиты от коррупции (ACL) для контекста планирования программы.
Понятия спикера, председателя и автора имеют общий человек. Я хочу ввести отдельный контекст управления персоналом, чтобы сократить количество дублирующихся людей и повторно использовать уникальных людей в контекстах планирования программы и управления документами, используя уникальный идентификатор человека и отображая информацию через составной пользовательский интерфейс. Позже мы хотим интегрировать другой контекст регистрации конференции с той же логикой ACL для другого стороннего API.
Как я узнал из многих книг, блогов и т. д., только контекст управления людьми должен владеть данными человека и создавать новые экземпляры. Следствием этого будет создание нового лица для каждого автора (синхронный вызов API) при импорте всех данных из внешнего API управления бумагой или, альтернативно, использование одного пакетного вызова в начале.
Это соединение слишком высокое? Должен ли я хранить дублированные личные данные авторов в контексте управления бумагой? Это кажется неправильным и затрудняет дедупликацию.
