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

It's unfortunately common to write adapters such as these. They cannot be
perfect in many cases and often are brittle. There is no "good" way to work
around this.

On Sunday, May 26, 2013, Matteo Moci wrote:

> **
>
>
> 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 =
>
>  
>


-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.