Re: ACID & Business Rules in non Trivial Domain Models

> 
> I see that ARs are excellent for very high load demands and yet
> extremely complex business constraints. 
> ...
> For most other cases it is my impression that is a cannon to kill a
> fly. Transaction facilities (ACID) become ubiquitous in the Enterprise
> so use them, do not replace them. To have a Domain Object mapped to a
> Table TCustomer, and Order mapped to a Table TORDER in the same
> database model, same database instance, same application, both
> potential ARs, IMHO it is even ridiculous to argue its usefulness from
> any technical point of view. 

Hi Nuno,
I've quoted what I think is the essence of your post above, and I
agree with it.  My (revised) 2c worth on this after reading a lot of
posts on this is:

1. ARs are worthwhile for reducing domain complexity: fewer things to
think about.  So do use them for this purpose.

2. ARs as consistency boundaries do make sense if deploying to a
grid-like architecture, but no sense if deploying to a traditional
RDBMS architecture.

The only question then is when would you need to move from RDBMS
persistence to grid?  Bearing in mind that an RDBMS is easy to
recover, and provides DSS as well as OLTP services, I think you would
have to have a very unusual app to want to move to grid for the
foreseeable.

Back to consistency in the CQS world

Hello All,

Let's say I am going to book a flight on a public and very busy
website.  When I enter that I want to fly from Johannesburg to Cape
Town on a specific day the system brings back a list of available
depature times for the day and has to reserve the number of seats just
in case I want to actually complete my booking.  Should I not complete
the booking or after some timeout the reserved seats are returned to
the pool.

Now keeping with the idea of a separate query domain / mechanism the
data in the reporting store needs to be rather consistent with what is
happening in the transactional domain store.

Sending a message off to be eventually processed will not wash.  We
can send a message and still wait for the response.  Part of this
process would require updating the reporting store since we cannot let
the user know 10 minutes later that their 'request' for a ticket came
too late and the required seats are no longer available.  Once the
user has completed the booking it is a done deal.

Is this a peculiar case?  Or is there a simple CQS solution that I'm
not seeing?

If I booked a ticket on a flight for tomorrow I would like to know
then-and-there whether I am flying or not.

Any ideas?

Regards,

Re: Back to consistency in the CQS world

Hi Eben,

Correct me if I'm wrong, but isn't this just an SLA issue? You're  
saying that the user can't wait 10 minutes to know that the required  
seats are available - but I'm sure they could wait some amount of time  
that's > 0. Probably, at least in computing terms, quite a bit > 0.

The web server sends a command and returns a response immediately,  
letting the user know it's processing their request, then when the  
reporting store is consistent enough, the web page refreshes with the  
result (say there's a background AJAX mechanism, whatever). This could  
all happen in a matter of seconds - it would only be under extreme  
load that it would take longer, but then at least your writes aren't  
failing because of contention (unless it's *really* high). I see this  
in many ticketing systems (as a user).

I think in this case it's just a matter of coming to an agreement on  
what are acceptable amounts of time, and in which circumstances these  
times are acceptable.

Does that help - or is it somehow side-stepping a deeper issue you  
wanted to get at?

Michael

On 01/03/2009, at 8:51 PM, Eben Roux wrote:

> Hello All,
>
> Let's say I am going to book a flight on a public and very busy

Re: Back to consistency in the CQS world

> Let's say I am going to book a flight on a public and very busy
> website.... Is this a peculiar case?  Or is there a simple CQS
solution that I'm
> not seeing?
> 

As you say, I don't think this is a particularly good candidate for
CQS.  I think that Greg works in the finance domain, and from the work
I've done in finance as a Sybase consultant, that domain is more
suitable; is often a clear separation between trading and risk
management (aggregating risk from trades vs limits etc); front-office
and back-office, if you will.   Not so for your example, though.

In a reply on a different thread about aggregates I was making the
point that I don't think using consistency boundaries as a means of
justifying aggregate roots makes sense for those of us using
traditional RDBMS systems.  These scale to a very high degree (1000+
xactns a second for < ~100ms response time for a system I saw last
week), so unless you know you are exceeding such limits, why bother to
partition your workload?

Cheers
Dan

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

Re: Back to consistency in the CQS world

Re: Back to consistency in the CQS world

Hey Michael,

We *could* call it a SLA issue but it is an issue none-the-less :)

I guess that the idea I get around CQS is that we aren't too 
concerned with consistency in general.  Now I know it has been 
mentioned that in some cases we may be more concerned with 
consistency as in this case.  So instead of sending a message and 
having the system get around to it we can actually wait for the 
response.  In such as case we may need to have a separate mechanism 
to handle this higher priority business --- I have seen something to 
this effect from Udi regarding *not* prioritizing messages but rather 
having a higher priority endpoint.  But even there the query part 
bugs me as the front-end sends a message to do a 'preliminary' 
booking (if you will) on all available flights and then send this to 
the reporting store --- but this will not work since, even using send-
and-wait, someone may query for the last seat but I have taken it so 
it shouldn't return the seat as available.  Therefore, it should be 
done within one consistency boudary.

Regards,
Eben

--- In domaindrivendesign <at> yahoogroups.com, Michael Hart 
<michael.hart.au@...> wrote:
>
> Hi Eben,
> 
> Correct me if I'm wrong, but isn't this just an SLA issue? You're  
> saying that the user can't wait 10 minutes to know that the 
required  
> seats are available - but I'm sure they could wait some amount of 
time  
> that's > 0. Probably, at least in computing terms, quite a bit > 0.
> 
> The web server sends a command and returns a response immediately,  
> letting the user know it's processing their request, then when the  
> reporting store is consistent enough, the web page refreshes with 
the  
> result (say there's a background AJAX mechanism, whatever). This 
could  
> all happen in a matter of seconds - it would only be under extreme  
> load that it would take longer, but then at least your writes 
aren't  
> failing because of contention (unless it's *really* high). I see 
this  
> in many ticketing systems (as a user).
> 
> I think in this case it's just a matter of coming to an agreement 
on  
> what are acceptable amounts of time, and in which circumstances 
these  
> times are acceptable.
> 
> Does that help - or is it somehow side-stepping a deeper issue you  
> wanted to get at?
> 
> Michael
> 
> On 01/03/2009, at 8:51 PM, Eben Roux wrote:
> 
> > Hello All,
> >
> > Let's say I am going to book a flight on a public and very busy
> > website.  When I enter that I want to fly from Johannesburg to 
Cape
> > Town on a specific day the system brings back a list of available
> > depature times for the day and has to reserve the number of seats 
just
> > in case I want to actually complete my booking.  Should I not 
complete
> > the booking or after some timeout the reserved seats are returned 
to
> > the pool.
> >
> > Now keeping with the idea of a separate query domain / mechanism 
the
> > data in the reporting store needs to be rather consistent with 
what is
> > happening in the transactional domain store.
> >
> > Sending a message off to be eventually processed will not wash.  
We
> > can send a message and still wait for the response.  Part of this
> > process would require updating the reporting store since we 
cannot let
> > the user know 10 minutes later that their 'request' for a ticket 
came
> > too late and the required seats are no longer available.  Once the
> > user has completed the booking it is a done deal.
> >
> > Is this a peculiar case?  Or is there a simple CQS solution that 
I'm
> > not seeing?
> >
> > If I booked a ticket on a flight for tomorrow I would like to know
> > then-and-there whether I am flying or not.
> >
> > Any ideas?
> >
> > Regards,
> > Eben
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>

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

Re: Back to consistency in the CQS world

Hey Dan,

I tend to agree :(

The issue, in my mind anyway, is that with CQS there is *no* 
consistency boundary spanning both the update message on the domain 
side and the correlated update message on the query side.

So can we do CQS in most parts of our system and ignore messaging 
where we need the 100% consistency?

Regards,
Eben

--- In domaindrivendesign <at> yahoogroups.com, "Dan Haywood" <dan@...> 
wrote:
>
> > Let's say I am going to book a flight on a public and very busy
> > website.... Is this a peculiar case?  Or is there a simple CQS
> solution that I'm
> > not seeing?
> > 
> 
> As you say, I don't think this is a particularly good candidate for
> CQS.  I think that Greg works in the finance domain, and from the 
work
> I've done in finance as a Sybase consultant, that domain is more
> suitable; is often a clear separation between trading and risk
> management (aggregating risk from trades vs limits etc); front-
office
> and back-office, if you will.   Not so for your example, though.
> 
> In a reply on a different thread about aggregates I was making the
> point that I don't think using consistency boundaries as a means of
> justifying aggregate roots makes sense for those of us using
> traditional RDBMS systems.  These scale to a very high degree (1000+
> xactns a second for < ~100ms response time for a system I saw last
> week), so unless you know you are exceeding such limits, why bother 
to
> partition your workload?
> 
> Cheers
> Dan
>

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

Re: Back to consistency in the CQS world

> I tend to agree :(
> 
> So can we do CQS in most parts of our system and ignore messaging 
> where we need the 100% consistency?
> 

Given the amount of discussion on this forum regarding CQS, it seems
like its an architecture that appeals to many, and I don't doubt that
it works and works well for Greg and others.  For myself, though, it
leaves me cold; it seems an unnecessary separation of responsibilities
for the vast majority of enterprise applications, and certainly for
those where I see DDD as being most applicable.  Implementation
details of CQS isn't something that's gonna keep me awake at night.

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

Re: ACID & Business Rules in non Trivial Domain Models

Hi Nuno, Hi Dan,

I mentioned before that I think that AR is a desirable, but probably
hard to achieve pattern in complex systems. You guys argue this in
much greater detail, and I am glad to see that I am not the only one
having trouble accepting this - in my eyes - simplified view of
consistency boundaries.

I haven't made up my mind yet what to think of this, still hoping for
the "aha" effect.

enjoy,
ramin

--- In domaindrivendesign <at> yahoogroups.com, "Dan Haywood" <dan@...> wrote:
>
> > 
> > I see that ARs are excellent for very high load demands and yet
> > extremely complex business constraints. 
> > ...
> > For most other cases it is my impression that is a cannon to kill a
> > fly. Transaction facilities (ACID) become ubiquitous in the Enterprise
> > so use them, do not replace them. To have a Domain Object mapped to a
> > Table TCustomer, and Order mapped to a Table TORDER in the same
> > database model, same database instance, same application, both
> > potential ARs, IMHO it is even ridiculous to argue its usefulness from
> > any technical point of view. 
> 
> Hi Nuno,
> I've quoted what I think is the essence of your post above, and I
> agree with it.  My (revised) 2c worth on this after reading a lot of
> posts on this is:
> 
> 1. ARs are worthwhile for reducing domain complexity: fewer things to
> think about.  So do use them for this purpose.
> 
> 2. ARs as consistency boundaries do make sense if deploying to a
> grid-like architecture, but no sense if deploying to a traditional
> RDBMS architecture.
> 
> The only question then is when would you need to move from RDBMS
> persistence to grid?  Bearing in mind that an RDBMS is easy to
> recover, and provides DSS as well as OLTP services, I think you would
> have to have a very unusual app to want to move to grid for the
> foreseeable.
> 
> It's possible you are an Amazon in which case you need massive OLTP
> performance.  But RDBMS do scale an amazingly long way.  This last
> week I was delivering a Sybase Performance course at a Telco software
> supplier.  We got hold of some monitoring data from production.  With
> a bank of 30 app servers (each with 10 CPUs) hitting a single Sybase
> instance with 32 CPUs, they were doing ~900 transactions per second. 
> Which is pretty good going.  And this was with Sybase running at about
> 1/3rd capacity.
> 
> So... if you are looking to scale beyond ~3000 transactions per
> second, AND you can afford to build your own reporting infrastructure,
> AND your SLAs are not too onerous to recover the system if it breaks,
> then perhaps you should also be thinking of ARs as consistency
> boundaries so you can deploy them to a grid architecture.
>

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

Re: Back to consistency in the CQS world

Hey Casey,

<<<
Any of those could report the situation has changed - after all, all 
the time the data is on the users screen, the data is inconsistent 
(view data is  now stale compared to the DB)
>>>

Not really.  It depends how you define stale.  When I enter the site 
and do a search for flights on a particular day for 2 seats those two 
seats are *immediately* reserved --- for the next 15 minutes anyway.

So if I complete my booking within 15 minutes I am *assured* of those 
seats.  So within this time window the data does not, can not, and 
will not change.

Regards,
Eben

--- In domaindrivendesign <at> yahoogroups.com, Casey Charlton <casey@...> 
wrote:
>
> There is no absolute consistency ... just the time for the requests 
to come
> back over the wire means it is inconsistent. And that is the bit 
you have to
> deal with - the only matter is not if there is inconsistency, but 
how long
> there is inconsistency for.
> Even with CQS separation, you could have sub-millisecond 
inconsistency ...
> but is that really the business objective?
> 
> Your scenario is a simple one, query for available seats, then a 
command to
> reserve, then a command to book, or a command to release the 
reservation.
> 
> Any of those could report the situation has changed - after all, 
all the
> time the data is on the users screen, the data is inconsistent 
(view data is
> now stale compared to the DB)
> 
> 
> 2009/3/1 Eben Roux <eben@...>
> 
> >   Hello All,
> >
> > Let's say I am going to book a flight on a public and very busy
> > website. When I enter that I want to fly from Johannesburg to Cape
> > Town on a specific day the system brings back a list of available
> > depature times for the day and has to reserve the number of seats 
just
> > in case I want to actually complete my booking. Should I not 
complete
> > the booking or after some timeout the reserved seats are returned 
to
> > the pool.
> >
> > Now keeping with the idea of a separate query domain / mechanism 
the
> > data in the reporting store needs to be rather consistent with 
what is
> > happening in the transactional domain store.
> >
> > Sending a message off to be eventually processed will not wash. We
> > can send a message and still wait for the response. Part of this
> > process would require updating the reporting store since we 
cannot let
> > the user know 10 minutes later that their 'request' for a ticket 
came
> > too late and the required seats are no longer available. Once the
> > user has completed the booking it is a done deal.
> >
> > Is this a peculiar case? Or is there a simple CQS solution that 
I'm
> > not seeing?
> >
> > If I booked a ticket on a flight for tomorrow I would like to know
> > then-and-there whether I am flying or not.
> >
> > Any ideas?
> >
> > Regards,
> > Eben
> >
> >  
> >
>

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