Как моделировать отношения с помощью источника событий

Question

В нашем сценарии у нас есть сущность Course для представления содержимого курса. Для каждого учащегося, посещающего курс, существует сущность CourseSession, отражающая прогресс учащегося в курсе. Таким образом, между Course и CourseSession существует связь «один ко многим». При использовании реляционной базы данных будет таблица курса и таблица course_session, в которых курс имеет уникальный идентификатор, а сеанс курса однозначно идентифицируется с помощью (courseId + studentId). Мы пытаемся смоделировать это, используя источник событий, и наша таблица событий похожа на следующую

-----------------------------------------------------
| entity_type | entity_id | event_type | event_data |
-----------------------------------------------------

, это нормально для хранения курса, есть courseId, который мы можем использовать как entity_id. Но для CourseSession нет атрибута intrinsi c id, мы должны использовать конкатенацию (courseId + studentId) как entity_id, что не совсем естественно. Есть ли лучший способ смоделировать такие отношения?

Answer 1

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

Итак, первый момент заключается в том, что хранилище событий - это не структура таблицы. Это список вещей, которые произошли в вашей системе. Тот факт, что студент потратил время на курс, - это то, что произошло. данные в форме таблицы, которую вы ищете.

Однако, поскольку прогноз не является источником истины, почему бы не подумать о создании ненормализованных таблиц, чтобы база данных не нуждалась в каких-либо соединениях или другие более сложные задания, и ваши данные уже будут сформированы так, как вам нужно для использования в вашем приложении. Это приводит к сверхбыстрым и высокоэффективным моделям чтения.

Ваши пользователи будут вам благодарны!

Answer 2

Я не эксперт, поэтому отнеситесь к этому ответу с недоверием

Но для CourseSession нет атрибута intrinsi c id, мы должны использовать конкатенацию (courseId + studentId) как entity_id, что не совсем естественно

Наличие составного идентификатора является нормальным, а иногда рекомендуется, чтобы ваша модель предметной области была согласована с языком предметной области.

Составной идентификатор можно смоделировать как объект значения: CourseSessionId { CoursId: string, studentId: string }.

в В дополнение к этому идентификатору домена c, вам может потребоваться добавить суррогатный идентификатор к объекту, чтобы удовлетворить некоторые внутренние требования:

• Некоторые ORM требуют наличия числового c идентификатор последовательности
• Некоторым хранилищам ключей и значений требуется ключ ULID
• Краткий и удобный для пользователя идентификатор

Суррогатный идентификатор является дополнительной информацией и должен быть максимально скрытым от уровня домена.

Есть ли лучший способ смоделировать такие отношения?

Шаблон источника событий, который я видел в контексте DDD, предполагает наличие потока событий для каждого агрегата.

В DDD, агрегат может рассматриваться как:

• Подсистема в ограниченном контексте
• У нее есть границы и инварианты для защиты его состояние
• Оно представлено сущностью (агрегат root) и может содержать другие сущности и объекты-значения.

Если учесть, что CourseSession сущность принадлежит к совокупному курсу , тогда вы должны продолжать использовать идентификатор курса как entity_id (или aggregate_id) как для событий, связанных с Course, так и для CourseSession.

в этом случае модель записи ( main model) может легко построить и представить отношения Course / CourseSessions, проигрывая поток Course.

В противном случае вы должны ввести модель чтения и определить проектор , который будет подписываться на оба * 1 056 * Course и CourseSession и создайте необходимые представления.

Эту модель чтения можно запросить напрямую или с помощью Course и CourseSession объединяет команды для принятия решений, но имейте в виду, что часто в конечном итоге согласовывается , и ваш бизнес должен терпеть это.