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