对于我的项目,这是一个潜在的大型网站,我选择将命令界面与查询界面分开.因此,提交命令是不返回结果的单向操作.这意味着客户端必须提供密钥,例如：
service.SubmitCommand(new AddUserCommand() { UserId = key,... });
显然,我不能使用一个int的主键,所以一个Guid是一个合乎逻辑的选择 – 除了我读到的任何地方,它的性能影响,这吓到我:)
但是,随后我还阅读了关于COMB Guids的信息,并且他们如何提供Guid的优势,同时仍然表现良好.我也在这里找到了一个实现：Sequential GUID in Linq-to-Sql?.
所以在我采取这个重要决定之前：有人有这方面的经验,有建议吗？
非常感谢！
路德
解决方法
您可能已经拥有一个自然键(如用户名,用于唯一标识用户),而不是向Guid提供Guid(对域可能无意义).这个自然键使用户的命令更加有意义：
>创建用户时,您将知道用户名,因为您将其作为命令的一部分提交.
>当您登录时,您知道用户名,因为用户将其作为登录命令的一部分提交.
如果您正确地索引用户名列表,则可能不需要GUID.验证这一点的最好方法是运行测试 – 插入一百万个用户记录,并了解CreateUser和Login如何执行.如果你真的看到一个严重的性能打击,你已经验证不利地影响业务,不能通过缓存来解决,然后添加一个Guid.
如果您正在进行DDD,则需要集中精力保持域干净,以便代码易于理解并反映实际的业务流程.引入一个人造钥匙是违背了这个目标的,但是如果你确定它为企业提供了实际的价值,那么继续.
