Re: Created DDD Exampe - Feedback?

"storing is done in the same context" yes likely distributed transactions.
Be very careful about using them.

On Tuesday, May 14, 2013, Mirko Sertic wrote:

> **
>
>
> Hi there
>
> Ok. In this example i *tried* to explain that messages are not forwarded
> to the target messaging system, because this system might be unavailable
> for a period of time. Events are stored in an EventStore, which is another
> kind of repository, nothing more. This might be confusing, as this has
> nothing to do with the Event Store Project. Storing events is done within
> the same transaction context as the application service invocation. The
> message forwarding is done once the messaging infrastructure is ready and
> available, here comes JMS or any other technology to play, and you are
> right, this is another transaction. The delayed messaging makes the two
> contexts eventually consistent, and of course we have to be careful about
> event deduplication and ordering. Storing every ID is a potential problem,
> it is just an example. Just storing the last id/timestamp is also
> feasible(but might also a problem in distributed environments if not
> synchronized on storage level), then we just have to take care of event
> ordering, the duplication problem is solved.
>
> Regards
> Mirko
>
> Am 11.05.2013 07:53, schrieb Greg Young:
>
>
>
> Also having read through everything.
>
>  Your method should probably be move on the aggregate not moved (you are
> telling the aggregate to do it the event would be moved)
>
>  There seems to be a lot of confusion with the usage of an "event store".
> You are really just using a message queue (unless I missed where you
> refactored to event sourcing).
>
>
> In this scenario, the transaction boundaries are at the
> ApplicationService. We can argue that the JMSMessageReceiver might call the
> CustomerService, and do it around a JMSTransaction. This is also a viable
> solution.
>
>
>  Along the same lines it seems you have introduced a rather large problem
> (though subtle) when introducing the domain event. You now need a
> transaction between you backing model and the message queue/event store
> that you introduced.
>
>  The tricky part is Event de-duplication. This can happen in case of
> infrastructure failure or system outage. This can be avoided by giving
> every Event an unique id, and track which ids were already processed.
>
> Another tricky part is Event ordering. This depends on the messaging
> infrastructure. If the infrastructure supports Event ordering, everything
> is alright. If not, this must be implemented by ourselves. In any case it
> is a good practice to design Events as an idempotent operation. This means
> that every Event can be processed multiple times, and every time with the
> same result without unwanted side effects.
>
>  These are actually pretty easy if done right. You can easily simulate
> transactional messaging over an at least once path. Generally you do not
> however want to hold every message id (imagine you get 100k/second).
> Instead a stream is a sequence treat it that way. Transactionally save your
> checkpoint (last completed message) with your processing. This will
> simulate transactional messaging. You can see this in practice in the
> durable subscriber in clientapi in the dev branch of
> github.com/eventstore/eventstore
>
>
>
>  Cheers,
>
>  Greg
>
> On Saturday, May 11, 2013, Greg Young wrote:
>
>> It's also got a great example of words in different contexts. "body
>> leasing domain" when I read that I thought it was a joke for a moment ;)
>>
>> On Saturday, May 11, 2013, mirko.sertic wrote:
>>
>>
>>
>> Hi@all
>>
>> I really like the idea of domain-driven design. Based on a project I am
>> working on at the moment I created a small example about what can happen to
>> application architecture if strategical and tactical patterns are applied
>> to the problem space.
>>
>> This example can be seen here:
>>
>> http://www.mirkosertic.de/doku.php/architecturedesign/dddexample
>>
>> It is far from being perfect, but it should show up a direction about how
>> to find subdomains, bounded contexts, aggregates, context integration and
>> application architecture.
>>
>> Any feedback is very welcome, so stay tuned and happy DDDing:-)
>>
>> Regards
>> Mirko
>>
>>    Reply via web post<http://groups.yahoo.com/group/domaindrivendesign/post;_ylc=X3oDMTJxdGpmODhyBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBG1zZ0lkAzI0MDQxBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTM2ODIxNTc3Ng--?act=reply&messageNum=24041>  Reply
>> to sender   Reply to group  Start a New Topic<http://groups.yahoo.com/group/domaindrivendesign/post;_ylc=X3oDMTJldjVldmozBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTM2ODIxNTc3Ng-->  Messages
>> in this topic<http://groups.yahoo.com/group/domaindrivendesign/message/24041;_ylc=X3oDMTM2aWg2cHB0BF9TAzk3MzU5NzE0BGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBG1zZ0lkAzI0MDQxBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTM2ODIxNTc3NgR0cGNJZAMyNDA0MQ-->(1)
>> Recent Activity:
>>
>>    - New Members<http://groups.yahoo.com/group/domaindrivendesign/members;_ylc=X3oDMTJmYmRlODloBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEzNjgyMTU3NzY-?o=6>
>>    6
>>
>>  Visit Your Group<http://groups.yahoo.com/group/domaindrivendesign;_ylc=X3oDMTJlcjE1czlhBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTM2ODIxNTc3Ng-->
>>  [image: Yahoo! Groups]<http://groups.yahoo.com/;_ylc=X3oDMTJkcjJmZ2pvBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMzY4MjE1Nzc2>
>> Switch to: Text-Only, Daily Digest • Unsubscribe • Terms of Use<http://docs.yahoo.com/info/terms/>•
>>
>> --
>> 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.
>
>
>  
>


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