SNAPSHOT + Event Sourcing

Question

Дьявол кроется в деталях. Я смотрю на реализацию событийных источников на существующих приложений общественного питания. У меня есть счет, который может быть связан с компанией, отделом в компании или сотрудником в компании.

Настройка

Вариант использования:

• Компания спонсирует мероприятие и оплатила еду.
• Есть клиенты, заходящие в отдел компании, и они заказали еду.
• Есть кафетерий и работник заказывает еду. Компания платит нам, но все еще нуждается в счете сотрудника.

Модель домена

Invoice
  -> invoice Id
  -> Status
  -> CompanyId 
  -> DeptId  
  -> EmployeeId 
  -> Balance

• Заполнено только название компании (компания, выставившая счет)
• companyId + deptId (отдел счетов)
• companyUd + deptId + employeeId (человек счета)

Таблица отношений

| p_key | invoice_id | Reltn_Table | Reltn_id |
|-------|------------|-------------|----------|
| 1     | 12345      | Company     | 245242   |
| 2     | 67890      | Company     | 1241243  |
| 3     | 79166      | Dept        | 534214   |
| 4     | 792131     | Dept        | 412213   |
| 5     | 489965     | Employee    | 412323   |

Предположим, что таблица dept и employee так или иначе связана с таблицей компании.

У меня есть другая таблица источников событий с моделью домена как INVOICE .

Таблица хранилищ событий.

| event_id | invoice_id | Event            | Payload |
|----------|------------|------------------|---------|
| 1        | 12345      | Invoice_InReview | JSON    |
| 2        | 12345      | Invoice_Billed   | JSON    |
| 3        | 12345      | Invoice_Paid     | JSON    |
| 4        | 12345      | Invoice_Reversed | JSON    |
| 5        | 12345      | Invoice_Paid     | JSON    |

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

* * ВОПРОС тысяча сорок-девять

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

Я изначально склонялся к созданию моментального снимка модели домена, но проблема по-прежнему остается, поскольку команда dept или companyId находится в JSON. Я не могу запустить события извлечения, основанные на этом.

Независимо от того, каким образом я вижу, мне придется позвонить, чтобы получить счет-фактуру / счета-фактуры, прежде чем я смогу применить событие или сделать что-нибудь. Есть ли что-то, чего мне не хватает, что поможет мне избавиться от Реляционной таблицы или это мечта дураков?

Также дополнительный вопрос

SNAPSHOTS сохраняются в той же таблице, что и хранилище событий, правильно? Тип события SNAPSHOT верно? Пожалуйста, поправьте меня, если я ошибаюсь

Answer 1

Моя арка. для вышеупомянутого пробэма будет выглядеть так:

Счет-фактура статус оплаченный InvoiceInfo

InvoiceInfo CompanyInvoiceInfo DebtInvoiceInfo EmployeeInvoiceInfo

InvoiceCreated InvoiceInReview InvoiceBilled

будет обзор событий

В основном все API на агг. для продолжения процесса требуется invoice_id:

Как пользователь получит его и вызовет API?

1. Когда счет-фактура генерируется и квитанция передается пользователю или на почту, где написан идентификатор счета-фактуры?
2. Список всех счетов сотрудника, компании или отдела? Мне нужна таблица (EmployeeInvoice) с (EmployeeId и InvoiceId и InvoiceStatus), таблица (CompanyInvoice) с (CompanyId, InvoiceId, InvoiceStatus) и DeptInvoice (DeptId, CompanyId, InvoiceStatus)

Отсюда можно щелкнуть Api для InvoiceUpdate, здесь также присутствует InvoiceId.

3. Случай, когда нужно открыть API для внешнего мира, например / updateInvoice? EmployeeId = или / updateInvoice? CompanyId = или / updateInvoice? DeptId = здесь уже известно из структуры API, какую таблицу нужно запрашивать.

Теперь, чтобы ответить на ваш вопрос:

1. Вам понадобится таблица для запроса идентификатора счета в случае, если в API InvoiceId нет мандата. Этот стол может быть сплющен, как я сделал выше, или может быть, как у вас там. Как и в модели Aggregate или EventStore, хранилище событий всегда основано на одном идентификаторе, и API много раз требует запрашивать его из diff. бизнес идентификаторы.

Answer 2

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

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

Хранилище событий находится на более низком уровне, и оно должно иметь следующие два метода:

interface EventStore
{
    EventStream loadEvents(aggregateId);
    void appendEvents(aggregateId, previousEventStream, eventsToBeAppended);
}

У него может другие методы, но на том же уровнеабстракция, подобная приведенной выше.

С другой стороны, хранилище Invoice с поддержкой источников событий будет иметь такой интерфейс:

interface InvoiceRepository {
   Invoice loadInvoice(invoiceId);
   void persistInvoice(invoiceId, invoiceNewEvents);
}

Здесь является примером такого (althought generic) хранилище.