我在找到他们需要与DDD + CQRS + EventSourcing的应用程序，我有一些麻烦搞清楚如何做到用户认证。
用户在本质上是我的域的一部分，因为它们是对客户负责。 我使用ASP.NET MVC 4，我一直在寻找只使用SimpleMembership。 由于登录和授权用户来说是一个同步操作，这是怎么解决的最终一致性架构？
我将不得不推出自己的身份验证系统，我保持非规范化的权威性表上读出侧的？ 如何处理这个安全性？ 我最终会存储在我的两个事件存储和我的视图表的密码哈希值？
这么多的问题，如果有人能提供一些线索，我将非常感激:)
tldr; 你怎么做用户认证的EventSource的应用？
并不是每一个“域”或业务组件使用国内长途或CQRS。 在大多数情况下，用户信息是真的眉头，因此通常可以不使用DDD为。 其他域名真的不依赖于实际的用户。 还有通常是被由各个域共享一个相关ID（用户ID）。
如果在你的系统中使用的消息，一种选择是注册和不CQRS管理用户，然后发送一个命令（RegisterUser {}用户ID）。 这将公布注册的事件的用户。 其他领域可以收听本次活动揭开序幕所需的任何工作流或敷设。
对于我们的MVC CQRS应用程序，我们最初开始断保持所有用户相关信息的域，并，就像有人提到，有一个RegisterUserCommand和UserRegisteredEvent。 存储域中的用户信息后，该事件得到了公布，并拿起读出侧，这也创造了一个用户，并产生所有的密码哈希值，等等。然后我们做了读取端身份验证：控制器将作出召唤出的“阅读模式身份验证服务”，以进行身份验证。
后来在路上，我们结束了完全重构这一点。 原来，我们需要访问用户相关的信息安全建设的授权我们的命令，这是我们在命令处理方面做了（我们的应用程序是一个分布式的应用程序，发送“射后不理”异步命令队列中，有在另一侧的自主监听器）。 安全组件则需要我们的域名参考去获取用户的个人资料，这导致了繁琐引用的问题。
我们决定把用户安全的东西进入，我们认为更多的一个重要组成部分，而不是属于域或阅读模式一个单独的数据库。 我们仍维持用户配置文件相关信息在域和读取模式（如职称，Twitter帐户网址等），但所有与安全相关的东西，比如密码哈希，都存储在这个中央数据库。 这是随后与服务，这是可用于两个MVC和命令authoriser访问。
我们实际上没有改变在UI不到什么东西，重构，因为我们只是调用的服务从注册用户命令处理程序来注册用户。 如果你要做到这样，你必须要小心这里让你的用户服务相关的操作幂等。 这是这样，你可以给你的命令，无副作用的重试的机会，因为你要更新2个来源的信息（ES和用户数据库）。
最后，你当然可以使用的成员资格提供此核心组成部分，但可以有缺陷这一点。 我们最终只是写我们自己 - 这是很简单的事。 这条链接到这个 ，它提供了如何实现它的一个很好的例子。
你应该考虑建立独立的实体，如：访问者（刚刚访问您的网站），用户（注册），客户（买了点东西）等尝试你的系统以这种方式分割，即使它会导致数据冗余的一点点。 磁盘空间不是一个问题，但修改系统的不同组件独立能力通常是非常关键的。
人们只用于防垢的目的创建非规范化的权威性表，只有当你的权威性读一边是性能瓶颈。 如果没有 - 通常是第三范式是很长的路要走。
在SimpleMembership方案通过SimpleMembership创建的所有表都可以看作是“用户”聚集的快照。 是的，他们会在你的事件存储复制一些数据。 你可能有这样的事件：UserCreated，UserUpdated，UserAssignedToRole等。
不要由会员供应商的名称被欺骗。 这不是那么简单，通常有很多的东西，你可以轻松地生活在没有（取决于您的域名）。 所以，也许你可以使用这样的事情： https://gist.github.com/Kayli/fe73769f19fdff40c3a7
