Re: Created DDD Exampe - Feedback?

Yes, you are right. Distributed transactions should be generally avoided 
due to scalability reasons.

Am 26.05.2013 14:18, schrieb Greg Young:
>
> "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
>>     <http://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-->
>>
>>             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.
>