Java 快照+；事件源

魔鬼在于细节。我正在考虑在现有餐饮应用程序上实施活动采购。我有一张发票，可以关联到公司、公司中的部门或公司中的员工

设置 用例：

• 该公司正在赞助一项活动，并已支付了食品费用
• 有客户来拜访公司的一个部门，他们已经点了食物
• 有自助餐厅，员工点菜。公司付给我们钱，但仍需向员工开账单

域模型

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

• 仅填写公司ID（票据公司）
• 公司ID+deptId（票据部）
• 公司ID+部门ID+员工ID（账单人）

关系表

| 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表与company表存在某种关联

我有另一个事件源表，其域模型为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    |

rest服务有时会传入员工、部门或员工id以将更新应用于发票

问题: 我想看看事件存储是否有一种方法来处理不需要查询关系表来检索发票然后对其应用事件的场景

我最初倾向于使用域模型的快照，但问题仍然存在，因为dept或companyId是JSON格式的，因此我无法基于此运行检索事件

无论我怎么看，在我可以应用事件或做任何事情之前，我都必须打电话检索发票。我缺少什么可以帮助我摆脱关系表，还是这是傻瓜的梦想

也是一个附带问题

快照保存在与事件存储相同的表中是否正确？事件类型是快照，对吗？如果我错了，请纠正我

我想看看事件存储是否有一种方法来处理不需要查询关系表来检索发票然后对其应用事件的场景

事件存储不应查询除其自身表以外的任何其他表。此外，事件存储区不应负责加载聚合并对其应用事件（对聚合重新水化）。这将是使用事件存储的存储库的责任

事件存储位于较低级别，它应该具有以下两种方法：

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

它可能有其他的方法，但是在与上面相同的抽象级别上

另一方面，支持事件源的发票存储库将具有以下接口：

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

---

是这样一个（尽管是通用的）存储库的示例。

My arch。对于上述问题，应如下所示：

发票合计 地位 支付 发票信息

发票信息 公司语音信息 债务发票信息 雇员发票信息

发票已创建 发票审查 发票

将是活动回顾

基本上所有的api都在agg上。应要求发票id进一步执行该流程：

用户将如何获取它并调用API

生成发票并将收据发送给用户时，还是通过写入发票id的邮件

列出员工、公司或部门的所有发票？我需要一个表（EmployeeInvoice），它有（EmployeeId和InvoiceId以及InvoiceStatus），一个表（CompanyInvoice），它有（CompanyId，InvoiceId，InvoiceStatus）和DeptInvoice（DeptId，CompanyId，InvoiceStatus）

从这里可以单击InvoiceUpdate的Api，这里也有InvoiceId

在这种情况下，需要向外部世界公开一个API，比如/updateInvoice？employeeId=或/updateInvoice？companyId=或/updateInvoice？deptId=这里，我们已经从API结构中知道需要查询哪种表 现在回答你的问题：

如果API InvoiceId中没有强制要求，您将需要一些表来查询发票id。那张桌子可以像我在上面做的那样被压平，也可以像你在那里做的那样。在聚合或EventStore模型中，EventStore始终基于单个ID，API多次需要从不同的业务ID查询它

---

因此，根据我的推断，如果api没有严格地从api获取发票Id。在访问事件存储之前，我需要一个关系数据库来检索发票id，对吗？同样，拥有快照也无法克服这一问题scenario@Praveen是的，没错。但我的回答的主要意思是，活动商店没有这个责任。