消息队列 - 消费者的最小工作量

Question

这个问题是关于建筑/设计的：

我有一个消费者需要执行 x 个任务，我应该什么时候考虑将消费者分解为更小的任务和/或将更小的任务添加到他们自己的消费者中？

例子：

消费者 FooBarShipping 确实

• 为报告添加数据库条目
• 为帐户添加数据库条目
• 为运输添加数据库条目
• 根据需要生成运输发票（PDF 或其他格式）
• 创建发货通知
• 为帐户创建通知

所以我的问题是，我何时将要点分解为较小的消费者？消费者运行良好，但我觉得它变得太大，需要重构为更小、更易于管理的流程。

每个要点都应该是它自己的消费者吗？我可以看到将它们分成三个消费者

• 数据库
• pdf（文件）
• 通知

但是，消费者应该做的最小工作单元是什么？我真的需要消费者来运行 sql 语句吗？

看过

• https://www.youtube.com/watch?feature=player_embedded&v=E708csv4XgY

在我看来，消费者希望完成基本任务，从而启动其他基本任务。

Answer 1

对于一般架构，您有六个模块，每个模块都希望分为：

• 1 添加用于报告的数据库条目
• 1 为帐户添加数据库条目
• 1 添加发货数据库条目
• 2 生成运输发票（PDF 或其他格式，如果需要）
• 3 创建发货通知
• 3 为帐户创建通知

如果您实施存储库模式，组 1 应分为 3 个存储库。每个存储库处理每个实体（报告、帐户、运输）；但可以提供插入、更新、删除和选择操作。

与第 3 组相同，我不认为通用通知对象（在我的术语中为类）是一件好事，因为它可以成长为 x、y、z 实体通知。

不过不用担心，您已经走在正确的道路上。如果我谈论依赖，构造函数注入，最好将其分离为 3 个对象。 FooBarShipping ship 方法的总体思路：

FooBarShipping.Ship(Invoice inv){
    invoiceRepository.InsertNew(inv);
    invoiceGenerator.GenerateInvoice(inv);
    invoiceNotification.Notify(inv);
}

InvoiceRepository.InsertNew 的总体思路：

InvoiceRepository.InsertNew(Invoice inv){
    reportingRepository.InsertNew(inv.Reporting);
    accountRepository.InsertNew(inv.Account);
    shippingRepository.InsertNew(inv.Shipping);
}

与 InvoiceNotification.Notify 的想法相同：

InvoiceNotification.Notify(Invoice inv){
    shippingNotification.Notify(inv);
    accoountNotification.Notify(inv);
}

不过，它可能需要针对您的数据结构和实现进行调整。但这是一般的想法。不过，您也可以参考此article (Refactoring to Aggregate Services)。