Re: Transactionally Consistency in DDD

That means that every method invoked on an aggregate must leave it
consistent (in a valid state according to business rules). So if the method
does something invalid then it must throw an exception, aborting the
operation and reverting any changes. It also means that many times you are
going to make most operations through the root in order to control the
parts of the cluster.
Ex: If you have a rule that states that a bookshelf can only store max. 5
books then giving public access to a list of books in the bookshelf class
won't be a good idea, because you can't control what the client code does
with that list. Instead you could use the root to add/remove books. The
root aggregate  is liable for all the elements of the aggregate.

*Joao Oliveira*
*Software Engineer*

*P:* +353 831 467 299 | *E: *[email protected]  | Connect with me
on Linkedin <http://ie.linkedin.com/in/jnicolau>

On Fri, Nov 28, 2014 at 2:10 PM, [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> I'm stuck at a quote from  Vaughn Vernon in his IDDD book. Here it goes:
>
>
> *"An Aggregate is composed of either a single Entity (5) or a cluster of
> Entities and Value Objects (6) that must remain transactionally consistent
> throughout the Aggregate’s lifetime." - Implementing DDD by  Vaughn Vernon*
>
>
> I'm trying to understand "transactionally consistent" that is mentioned
> here. Is it the behavior of the repository that makes sure the aggregate
> should be consistent when it is read or committed from the database.
>
>
> Or it the consistency of the aggregate when it is operated in memory and
> goes through state changes and shows consistent behavior.
>
>
>  
>