DDD CQRS/Event sourcing confusion - Entities vs Aggregates and Value objects

[Sune42]

Hi

I have been watching both of Greg's oline CQRS classes and I got
confusions that I would like get settled.


1. So I am new to DDD/CQRS but I understand so far that:

* Entity represents a single thing, like customer, Person...
* Aggrgates represents things that got relationships internally like
Orders (with orderlines...)


In Greg's talk he mostly talks about the event sourcing of aggregates,
but what about entities? How are they persisted?

Do we treet entities as Aggregates (As they are quite similar?) ? or
do we store the entities separate from aggregates? (in a table
structure similar to the aggregates?) Or do we only use aggregates
and the "entities" concept is not used?


Or do we say that the event handlers are the "entities?"


2. Do we put business logic inside the aggregate root objects? or do
we put them outside in the event handlers/entities?



3. Value objects, (I know they are read-only data), but I guess they
can change over time as well.

Can we store them and treat them the event sourcing storage as well so
that we can go back in time to
retrieve the value object at a specific version?

Or do we handle this completly outside the event storage?

//Sune

[Greg Young]

An aggregate is made up of entities and value objects.

--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

[Milo Hyson]

Sune,

The word aggregate can be a source of some confusion for those new to
DDD. While in English an aggregate is a combination of elements, this
is not always the case in DDD. In his original book, Eric Evans used
the term to mean a collection of objects treated as a cohesive whole
for the purposes of a transaction. But it has been generalized to
include even single entities. This unfortunately is inconsistent with
the English definition of the word, and by my reading of Evans' book
it's also completely pointless.

- Milo

[Greg Young]

Aggregates are pointless?

--

[Milo Hyson]

That's not what I wrote, no.

- Milo

On Feb 27, 12:58 pm, Greg Young <gregoryyou...@gmail.com> wrote:
> Aggregates are pointless?

[Greg Young]

a single entity in an aggregate is pointless?

--

[Sune42]

Thanks!

That explains alot!

So that means that I do everything via aggregates, operations on both
single entities and multiple entities.

Do you have any recommendation on how to store value objects? Perhaps
I can treat them as special
"read only" entities with no behavior? Becuse i guess it would be
useful to ge tthem into the event storage
as well along with all the other events in the system so that I can
version value objects over time?

[mynkow]

Value objects are part of the Aggregate. You save them with the AR

[Milo Hyson]

No, I said the generalization of an aggregate to include a single
entity is, by my reading of the book, pointless. The purpose of an
aggregate as originally stated is to create a level of cohesion
between related objects by enforcing certain inter-object invariants.
This cannot occur with only a single object since there is nothing
else with which to be cohesive. Additionally, a single object is
already cohesive due to its own internal invariants. Put another way,
the boundary of an aggregate with only a single element is
indistinguishable from the boundary of the element itself. Thus, in
this situation, the aggregate concept adds nothing and is unnecessary.

- Milo

[Greg Young]

Except that defines a consistency boundary which is not part of the
definition of a single element

--

[√iktor Klang]

On Sun, Feb 27, 2011 at 11:55 PM, Greg Young <gregor...@gmail.com> wrote:

Except that defines a consistency boundary which is not part of the
definition of a single element

+1

 

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[Milo Hyson]

Consistency with what?

- Milo

[Greg Young]

The whole point of an aggregate boundary is that everything inside is
consistent.

On Sunday, February 27, 2011, Milo Hyson <milo...@gmail.com> wrote:

--

[Milo Hyson]

It was my understanding that individual objects are supposed to
already be internally consistent. Is this not the case?

- Milo

[Caleb Vear]

I believe the idea is to be consistent when storing the data as well.  Across aggregate boundaries it is possible for one aggregate to be out of sync with another aggregate for a period of time (think before an event is handled or something similar).

Caleb

[satish venkatakrishnan]

mean while .. value objects are not read only ..its immutable which means tat can be changed at a point in time.. Please correct me if  i am wrong

[Nuno Lopes]

An Aggregate is a techical design construct.

At runtime what it means is that all access is serialized (mutex). Entities on the other hand don't impose such constraints. You can have an entity handling multiple request at the same time.

The idea of such serialization (process changes as a unit) is that otherwise maintaining consistency would be a hard task to achieve.

Sent from my iPad

[Nuno Lopes]

Combining the Aggregate pattern with an Entity is of course an Entity whose access is serial, aka performs only one task at a time.

This is important especially in entities that live beyond the lifetime of a running process, aka persisted.

Sent from my iPad

On 27 de Fev de 2011, at 04:55 PM, Sune42 <sun...@hotmail.com> wrote:

[Tom Janssens]

> mean while .. value objects are not read only ..its immutable which means
> tat can be changed at a point in time.. Please correct me if i am wrong

+1

On 28 feb, 03:58, satish venkatakrishnan <satish...@gmail.com> wrote:
> mean while .. value objects are not read only ..its immutable which means
> tat can be changed at a point in time.. Please correct me if  i am wrong
>

> On Mon, Feb 28, 2011 at 6:39 AM, Caleb Vear <caleb.v...@gmail.com> wrote:
> > I believe the idea is to be consistent when storing the data as well.
> >  Across aggregate boundaries it is possible for one aggregate to be out of
> > sync with another aggregate for a period of time (think before an event is
> > handled or something similar).
>
> > Caleb
>

[Nuno Lopes]

mean while .. value objects are not read only ..its immutable which means tat can be changed at a point in time.. Please correct me if  i am wrong

It just means that after set they cannot be changed. 

Sent from my iPad

[Nuno Lopes]

On values, it also means that you can change the value of a property by simply setting it to some other value. 

Sent from my iPad

On 28 de Fev de 2011, at 02:58 AM, satish venkatakrishnan <sati...@gmail.com> wrote:

[alphadogg]

1. Entity represents a thing/concept/noun in the system. Aggregate represents a set of entities treated as a whole for purposes of consistency and transaction. Relations don't necessarily have anything to do with it, although are common. Think of two key design concepts: a) "Program to an interface, not an implementation", and b) "Favor object composition over class inheritance." So, an aggregate root is the interface to that composed group of entities (and value objects), which is the aggregate.
2. The simplest way to say it is: Does it involve one entity? Put it in the entity. Does it involve one or more entities in an aggregate? Put it in the aggregate root. Does it involve more than one aggregate? Put it in a domain service object. Of course, devil lies in the details. Also, events are messages, not business logic.
3. I'll leave event sourcing to the pros...
   

[Greg Young]

Can you set your email client to include what you are replying to? I
often get confused with context reading your emails.

--

[alphadogg]

Sorry using Google Groups' interface for the first time and their tree view is atrocious. Thanks for the heads up, I'll try to be more careful.