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

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船舶方法的一般想法：

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)获取参考资料。