Re: Transactionally Consistency in DDD

The way I understand it is as you explained in your second paragraph, that
any external operation on the class should leave the aggregate in a valid
state. Since external code is calling the aggregate method, such as
person.UpdateAddress(address); by the time the code has completed the
aggregate root and all its entities will be valid and all rules checked to
allow the operation to have completed and state modified (or not).

I believe transactions across a repository write would be for concurrency
detection not for assurance and implementation of business logic.

Appreciate any pointers too if my understanding is wrong!
On 28 Nov 2014 18:10, "[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.
>
>
>  
>