Re: Created DDD Exampe - Feedback?

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.
>