Question

For my project, which is a potentially big web site, I have chosen to separate the command interface from the query interface. As a result, submitting commands are one-way operations that don’t return a result. This means that the client has to provide the key, for example:

service.SubmitCommand(new AddUserCommand() { UserId = key, ... });

Obviously I can’t use an int for the primary key, so a Guid is a logical choice – except that I read everywhere about the performance impact it has, which scares me 🙂

But then I also read about COMB Guids, and how they provide the advantages of Guid’s while still having a good performance. I also found an implementation here: Sequential GUID in Linq-to-Sql?.

So before I take this important decision: does someone have experience with this matter, of advice?

Thanks a lot!

Lud

Answer 1

Instead of supplying a Guid to a command (which is probably meaningless to the domain), you probably already have a natural key like username which serves to uniquely identify the user. This natural key make a lot more sense for the user commands:

1. When you create a user, you know the username because you submitted it as part of the command.
2. When you’re logging in, you know the username because the user submitted it as part of the login command.

If you index the username column properly, you may not need the GUID. The best way to verify this is to run a test – insert a million user records and see how CreateUser and Login perform. If you really to see a serious performance hit that you have verified adversely affects the business and can’t be solved by caching, then add a Guid.

If you’re doing DDD, you’ll want to focus hard on keeping the domain clean so the code is easy to understand and reflects the actual business processes. Introducing an artificial key is contrary to that goal, but if you’re sure that it provides actual value to the business, then go ahead.