Ben*_*min 8 domain-driven-design cqrs domain-events
我正在采用DDD概念来设计我们的下一个项目,更具体地说是CQRS.
在阅读了很多东西后,我现在正试图实现一个简单的概念验证.
事情是我开始后就被困住了:p
我正在尝试将此方法应用于简单的用户注册过程,其中的步骤是:
从实现的角度来看,到目前为止我得到的是:
就是这样,控制器动作不知道任何一个.
所以,我的猜测是,因为这个上下文中的所有东西都要同步完成(除了电子邮件发送),我可以使用直接/同步命令总线,并在控制器操作中,在命令总线调用之后,我可以查询对于只读用户(查询数据库),如果它存在假设一切顺利,那么我可以给用户一个确认消息.
自动登录过程由事件处理程序处理.
假设这是正确的,如果出现问题怎么办,如何通知用户正确的信息？
我们可以通过互联网找到的文章中经常使用一个常见的例子:客户使用过期的信用卡支付订单.系统接受请求,通知用户一切正常,但用户几分钟后收到一封电子邮件,告诉他无法处理他的订单.
嗯,在许多情况下,这种情况是可以接受的,但对于其他一些情况,这是不可能的.那么处理这些用例的例子在哪里？:p
谢谢 !
人为示例的问题在于，您可以改变对“域”如何运行的想法，因此专门讨论此示例几乎没有用处。你似乎放弃的基本前提是我们必须假设事情会顺利进行。其他一切都与风险和减轻风险有关。举个例子，如果我问你，如果我在 10 万个用户注册中丢失了 1 个怎么办？如果我输了十分之一怎么办？为什么会发生这种情况？那时我有更大的问题吗？当系统恢复在线并按预期工作时，未来的用户是否可能再次注册？那会是什么时候呢？如果我们监控我们的服务质量并阻止用户注册，因为我们无法保证他们与我们品牌相关的质量，该怎么办？如果服务器爆炸或者数据中心被核武器炸毁怎么办？我们想防止这种情况发生吗？你看，没有正确答案。只是各种深浅的灰色。那么我们如何降低风险呢？我们可以使事情同步，但这只是在有限的时间点上的保证。如果我必须恢复 2 小时前的备份（例如因为磁盘损坏）怎么办？（也许）注册用户流失了 2 个小时。这些事情发生了……我只是想指出我认为的错误安全感的相对性。缓解它，投资于你不能承受损失的东西，确保你有良好的审计跟踪。可能不是您正在寻找的答案......