Re: Generate events from consecutive entity (aggregate?) statuses

That's a good point, Mauro,
but I do not have control on that part: the entities are not inside my
system,
and that's why I have to do this weird polling thing.
If I could, your solution would be much cleaner!
Maybe calling them aggregates was a bit misleading.



On Sun, May 26, 2013 at 10:06 AM, Mauro Servienti <[email protected]> wrote:

> **
>
>
>  My question is:****
>
> ** **
>
> why there is, as far as I understood, something (the job) that polls the
> aggregate for its status instead of simply having the aggregates that fires
> events on status changes?****
>
> ** **
>
> The event carries the status change:****
>
> ** **
>
> class AggregateNameChangedEvent****
>
> {****
>
>     DatetTime When;****
>
>     String OldName;****
>
>     String NewName;****
>
> }****
>
> ** **
>
> .m****
>
> ** **
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Matteo Moci
> *Sent:* venerdì 24 maggio 2013 23.26
> *To:* [email protected]
> *Subject:* [domaindrivendesign] Generate events from consecutive entity
> (aggregate?) statuses****
>
> ** **
>
>
>
>
> ****
>
> Hi all, ****
>
> I am quite new to ddd and all its related aspects like EventSourcing,
> CQRS, etc… ****
>
> and lately I discovered this list as really helpful to understand both the
> basic or subtle and more advanced concepts. ****
>
> ** **
>
> Currently, I'd like to have some feedback about the design of a part of a
> system, since I have lots to learn in this context. ****
>
> ** **
>
> The system continuously monitors external entities (aggregates) status: **
> **
>
> this means that, for example, a job J is launched now and asks for the
> status of an Aggregate A to another system, ****
>
> and stores its snapshot in an internal repository. ****
>
> ** **
>
> Based on the previous snapshot of A in the repository, after storing the
> current A snapshot, the job J should generate a list of events related to
> the A status change: for every type of change that A can have, there is a
> specific type of event that should be produced and sent in the system for
> further processing. ****
>
> ** **
>
> If the A aggregate at time 0 had a field name = "Anna" and at time 1 is
> name = "Anna F.", the event fired should be something like "entity A
> changed name to 'Anna F.' at time 1". ****
>
> ** **
>
> Storing all the sequence of snapshots of every aggregate provides the
> system also a way of replaying them, producing again the events that were
> produced in first instance. This will help also testing, I think. ****
>
> ** **
>
> How does that sound to you? ****
>
> Do you have some advice or relevant links to learn from? ****
>
> ** **
>
> Thanks! ****
>
> Matteo****
>
> ** **
>
> PS: I pasted a snippet here [1] to illustrate the snapshot repository APIs
> that I came up with until now. ****
>
> [1] https://gist.github.com/mox601/5646540****
>
> ** **
>
> ** **
>
> --
> Matteo Moci
> http://it.linkedin.com/in/matteomoci
> http://about.me/matteomoci/bio ****
>
>
>
>
> ****
>
> ****
>
>  
>



-- 
Matteo Moci
http://it.linkedin.com/in/matteomoci
http://about.me/matteomoci/bio