Domain Objects & Event Sourcing

Imported from Google Groups
#1

One of the weird aspects of event sourcing is, that domain objects
don't contain all attributes that belong to the object.

Example:
http://code.google.com/p/axon-auction-example/source/browse/trunk/auction-command-server/src/main/java/org/fuin/auction/command/server/domain/Category.java
(The category has a name that is only visible in the constructor
because none of the methods needs it - It's only necessary for the
queries)

Is this really a good idea in respect to DDD? At the moment there is
no place in the code where I can see what is really in the domain
object. This is at best confusing...

I'm thinking about an abstract base class for such objects that has
all attributes and protected setter/getter for access by the concrete
subclass. This abstract base class could also be automatically
generated from a model (like UML).

What do you think?

@Allard:
Could you add a link from the Axon project page to the example
project?

#2

Hi Michael,

my opinion on this is that the implementation is spot-on (with regards to dealing with the name property). The domain model in the command side should focus on behavior, not on state. The behavior states that the instance is created with a name. Perhaps you can also change the name. In that case, you’ll also have a changeName method. But since none of the behavior depends on the current state of “name”, it doesn’t contain a field.

The query model will focus on state. It will therefore have a property “name”, which is read-only for any component other than the event handler.

My 2 cents.

Cheers,

Allard

PS. I will create the link right away.

#3

Hi Allard,

But how do I talk to the customer about the domain model?

In traditional J2EE applications I'd simply create a UML diagram with
the domain objects - This isn't possible with event sourcing as I
don't have a central place for all informations about a domain object.
Attributes like the above "name" property are only logically part of
the domain object but not physically modeled at the command side.

How do you handle this?

Cheers,
Michael

#4

I talk to my domain expert in terms of commands and events. What can a user do, and what should happen when he does that? I think it’s important to explain your domain expert what CQRS means in terms of domain modeling. My experience is that most domain experts don’t have too much trouble to understand it on the higher level.

If a Domain expert says “a category has a name”, you should ask: “what can I do with the name?” and “is the name used in any business rules when doing other things?”. If his answers are “you set it and can change it later” and “no, it’s just a label”, then the conclusion is that the name itself doesn’t have any meaning in the command model. This approach has worked for me, so far.

Cheers,

Allard