RE: Re: Validation in CQRS Journey Conference project

Only if you work in parallel, but if the endpoint that handles the CreateConferenceMessage and starts the creation saga is a single thread endpoint you are sure that all the requests are serialized, so in a second request you can check if someone else has already "stolen" that specific slug.

In the above case you cannot scale, but in your scenario I do not see the problem at all, if I am not missing anything, it exactly like two different persons in two offices doing the same business: create a conference;

a) check if someone else is already *creating* a conference with details conflicting with mine;
b) if no, *reserve* the details, such as slug, for my task;
c) start the create conference process;

since the b step is done against a shared resource, such as a db, there cannot be conflicts in that.

What am I missing?
.m

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of wonderfulworldofpingpong
Sent: lunedì 3 giugno 2013 22.46
To: [email protected]
Subject: [domaindrivendesign] Re: Validation in CQRS Journey Conference project

The conflict will happen if two users create the same conference.

--- In [email protected], Mauro Servienti <mauro@...> wrote:
>
> What you are describing is a workflow/saga, that is async, and works pretty fine in your scenario.
> The only scenario where things get complicated is when, as you noticed, validation involves more BCs.
> In this case is the entry point BC that can take a decision:
> 
> -          Create Conference: Is there already a conflicting create conference process?
> 
> o   Yes: fail immediately;
> 
> o   No: start the creation process;
> 
> ?  ValidateRequest;
> 
> ?  ....and so on;
> 
> .m




------------------------------------

Yahoo! Groups Links







------------------------------------