Home

Working draft!

CQRS Code Smells

CommandHandlers

• Anything happening in command handlers besides invoking the aggregate root is a code smell.

Aggregate Roots

• Don't create aggregate roots from aggregate roots
• Aggregate roots should just fire off events and do pure business logic. Everything the aggregate root needs to do this should be given to it, it shouldn't have to go making database calls or other stupid things.
• If you're going crazy dealing with asynchronous stuff you probably need an entity or implement a saga. Don't jump through hoops to make sure something has processed.
• Don't fire commands from here, just events.
• If you have a large aggregate root that doesn't really do much, it just sends off events, you're probably okay.
• If you have a large aggregate root that does a lot of logic, and does all kinds of magic, you're not okay.

Denormalizers

• Use denormalizers for denormalizing data. You already have a bus or queue system in place, so if you need to do other things, like send off an e-mail, set up another event handler and deal with it somewhere else.

Other event handlers

• Don't send off events from here, fire off commands. I have an event handler that does some processing and depending on how this long running process goes, needs to update the UI. I send off commands for this.

General code smells

• If it looks like it should not be done in CQRS, seems simpler to not do it in CQRS and has no driving reason to do it CQRS, don't do it in CQRS.
• If you can't make your program asynchronous without changing a lot of things, CQRS is the wrong design pattern to use.
• CQRS can make simple things complicated, but can make complicated things simple. If it is making something simple complicated, you're doing it wrong.