tux*_*ear 15 authentication authorization cqrs event-sourcing event-store
我正在研究使用DDD + CQRS + EventSourcing制作应用程序,我在确定如何进行用户身份验证方面遇到了一些麻烦.
用户本质上是我的域的一部分,因为他们负责客户.我正在使用ASP.NET MVC 4,我希望只使用SimpleMembership.由于登录和授权用户是同步操作,如何在最终一致的架构中解决这个问题？
我是否必须滚动自己的auth系统,在读取端保留非规范化的auth表？如何处理这个的安全性？我最终会在我的事件存储区和视图表中存储密码哈希值吗？
这么多问题,如果有人能说清楚,我会非常感激:)
tldr; 你如何在EventSource应用程序中进行用户身份验证？
Jon*_*eus 12
并非每个"域"或业务组件都必须使用DDD或CQRS.在大多数情况下,用户信息非常肮脏,因此您通常不能使用DDD.其他域并不真正依赖于实际用户.通常有一个由各个域共享的相关ID(UserId).
如果在系统中使用消息传递,一种选择是注册和管理没有CQRS的用户,然后发送命令(RegisterUser {UserId}).这将发布用户注册的事件.其他域可以收听此事件以启动所需的任何工作流程或AR.
jac*_*ida 12
对于我们的MVC CQRS应用程序,我们最初开始在域中保留所有用户相关信息,并且像有人提到的那样,有一个RegisterUserCommand和一个UserRegisteredEvent.在域中存储用户信息之后,该事件在读取端被发布和拾取,这也创建了用户并生成了所有密码哈希等.然后我们在读取端完成了身份验证:控制器将创建一个呼叫"读取模型身份验证服务"以进行身份验证.
在后来的路上,我们最终彻底重构了这一点.事实证明,我们需要访问用户相关信息以建立安全性来授权我们的命令,这是我们在命令处理方面完成的(我们的应用程序是一个分布式应用程序,它将'fire and forget'异步命令发送到队列,另一方面是一个自主的倾听者.然后,安全组件需要引用我们的域来获取用户配置文件,这导致了繁琐的引用问题.
我们决定将用户安全性内容放入一个单独的数据库中,我们认为它更像是一个中心组件,而不是属于域或读取模型.我们仍然在域中维护用户配置文件相关信息并读取模型(例如职位,推特帐户URL等),但所有与安全相关的内容(如密码哈希)都存储在此中央数据库中.然后可以通过MVC和命令授权者都可以使用的服务访问它.
我们实际上不需要为此重构更改UI中的任何内容,因为我们只是调用服务来从register user命令处理程序注册用户.如果你打算这样做,你需要在这里小心,使你的用户服务相关的操作是幂等的.这样您就可以为命令提供无副作用的重试机会,因为您正在更新2个信息源(ES和用户数据库).
最后,您当然可以使用成员资格提供程序来处理这个中心组件,但可能存在陷阱.我们最后只是编写自己的 - 这很简单.那篇文章链接到这个,它提供了一个如何实现它的一个很好的例子.