I started with my first application that uases event sourcing. So I started with the quick start guide which was quite clear and easy. Now I implement some real-world entities where I’m a bit unsure how granular commands should be.
Example: For creating a new domain object there is a simple (crud like) form. The user can add some basic information there (e.g. title, description). Later it would be possible to change those values (similar or same form). So should I create one CreateEntityCommand containing all those fields or should I create separate commands for each field?
It might be that the user later edits only the title. So same question here. Should I use a UpdateEntityCommand and let the domain object decide that only fields that are not-null on the command gets changed? Or should I create a command for each field?
there is no real answer to this one.
Each of the approaches will work, and have some drawbacks. Typically, you would have 1 command for each UI action (or task). However, if you have an auto-save form, it would make more sense to group some of the fields together. Things like an address would be an example of things to group together.
My advice would be to do a proof-of-concept. That would allow you to get a feeling on whether the granularity works.
I’m almost in the same situation as new, being new to CQRS, and have had many of the same questions as you. I have at the same time as trying to learn CQRS also started to read upon DDD (Domain Driven Design). First I bought the “blue book” from Eric Evans (http://dddcommunity.org/book/evans_2003/), but now I’m reading a book from Vaughn Vernon (Implementing Domain-driven design). The key here, I think, is to think about your domain and what you want your system to do. For example, the case I’m working on at the moment, I’m ONLY looking at the behavior of the various objects/things I need, and not the data (which you start of with). After 15 years of Java EE development I’m used working on the data, making objects with getters and settes, and not focusing on the behavior of the objects/things…you’ll end up with an anemic domain model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) I think (at least that is my experience).
So, what I’ve done differently this time when starting to learn CQRS, Event Sourcing and DDD is to in the first place purely look at the domain and the behavior of the various objects/things/bounded contexts and not the data. I’m forced to think about how they will interact, and this way (at least I think), the data and also which command you need to update various pieces of data will come naturally!!
I’m just scratching the surface of CQRS/Event Sourcing/DDD, so maybe Allard can share some more insights to modelling to make the best out of Axon for you.
I think Viggo is absolutely right here. Reading about DDD will certainly help in the design of a CQRS based system. In the end, you could see CQRS as a little extra icing on a DDD-cake (you can’ really use the icing on its own).
Behavior should always be first thought. What I do in domain modelling sessions is ask domain experts “what can tell this <> to do, and what will it then do?” You get sentences like “I can tell a Game to play a card. It will then play that card and the it is the next player’s turn”. So “Play a Card” is a command. The events are “Card Played” and “Turn Changed”. Once that is clear, you start asking “what information do I need to play a Card?”. That’s when the data is assigned to commands and events.
This is exactly the type of exercises I do in my training (in cooperation with Goto Academy). Once the modelling is done, implementing it with Axon should be a walk in the park.