Within the world of data storage, reading and writing data are really two very distinct things. When writing, you want something that can write quickly and has an efficient storage structure. In the relational db world, this usually leads to normalization of data structures to remove duplication.

If you look at the same problem from the read side, there is a desire to have as many indexes as possible. The more indexes a set of tables has, the faster queries will be against those tables. Also, a highly normalized model, while efficient in storage, can be a burden to query against.

When faced with a problem like this, where you have to satisfy two concerns that are in conflict with their needs, why keep them together in the first place? Wouldn't it be better to separate them into their own storage models and systems, each optimized for their own needs? This kind of approach is at the heart of what we'll cover in this chapter, using a pattern called Command...