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

There is a second problem. You often lose why something was changed.

On Sunday, May 26, 2013, Mauro Servienti wrote:

> **
>
>
>  The main pain point with polling is that you can easily loose changes
> that happens between 2 polls.****
>
> ** **
>
> If you are running on a system that support some sort of triggers (such as
> Sql Broker, RavenDB changes API, whatever) you can plug some logic to
> intercept all changes and create an anti-corruption layer that listen to
> the triggers and pushes events to your system.****
>
> ** **
>
> .m****
>
> ** **
>
> *From:* [email protected] <javascript:_e({}, 'cvml',
> '[email protected]');> [mailto:
> [email protected] <javascript:_e({}, 'cvml',
> '[email protected]');>] *On Behalf Of *Greg Young
> *Sent:* domenica 26 maggio 2013 11.03
> *To:* [email protected] <javascript:_e({}, 'cvml',
> '[email protected]');>
> *Subject:* Re: [domaindrivendesign] 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
>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
>
>
> ****
>
> ****
>
>   
>


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