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

Thanks for the good insights,
In some way, I am not completely off track!

About your suggestions:
why something changed: this system is not interested much about the 'why',
but I understand that for other systems it may be really important;
loosing changes between 2 polls: also in this case the system requirements
are ok with this, we don't need to be 'complete'.

I was thinking about what timestamp should the produced events have.
Since I don't have knowledge of the exact time in which "Anna" changed name
in "Anna F. ", I think the event fired will have the timestamp in which the
polling job ran.

Thanks again for your time!
Matteo



On Sun, May 26, 2013 at 2:15 PM, Greg Young <[email protected]> wrote:

> **
>
>
> 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] [mailto:
>> [email protected]] *On Behalf Of *Greg Young
>> *Sent:* domenica 26 maggio 2013 11.03
>> *To:* [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.
>
>  
>



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