我正在尝试将我们的大球体系结构中的一些部分分离,并确定了几个明显可以选择使用CQRS来提供更具弹性和可扩展性的解决方案的边界.
典型示例:当客户下订单时,我们在订单提交付款时批准其线程,由销售系统批准等等.
这可以全部异步处理 - 允许我们在支付处理系统不可用时接受和排队订单等 - 但我不确定如何管理客户的UI数据.
换句话说 - 他们下订单.他们的订单排在队列中.如果他们在五秒钟后重新登录帐户并点击"查看订单" - 会发生什么?
如果我从中央仓库(或从基于该仓库更新的缓存)中抽取它,那么用户将不会看到他们的订单并且可能会尝试再次放置它 - 或者给我们打电话和恐慌.
如果我从本地数据库中绘制它,那么我有维护另一个订单数据库的开销- 这需要在负载均衡的环境中同步,并且似乎破坏了CQRS的许多优点.
我想在很多地方做这件事 - 而且并非所有这些行动都像确认订单一样重要; 在某些情况下,它就像客户更改电话号码一样简单 - 所以他们并不是所有我只能说"非常感谢,我们会向您发送确认电子邮件"的情况 - 因为发送确认电子邮件每次修改记录的邮件都让我觉得有些过分.
我应该看看任何模式或解决方案来帮助解决这个问题?
值得考虑的是"用户"收件箱:用户可以在应用中查看"进行中"命令的位置.当他已经移动到另一个屏幕上时,您也可以将通知"推送"回用户的UI,但仍然存在于您的应用中.当用户重新登录时,这也可能是一个选项.
另一个选择可能是伪造同步体验,即等待并在后台进行轮询,所有事情都是异步发生的.当然,这也可能涉及包括超时,但我认为这些也包含在今天的同步处理中.
最重要的是,您可能希望通知并征求最终用户对他们如何体验您的应用及其行为的反馈.
无论有人告诉你什么,如果你想要优雅地处理这个问题,你需要付出一些努力.