Examples for reservation/booking aggregate structure

[Werner Clausen]

Hi,

 

I wonder if anyone else here has developed a reservation system? Probably yes, and before we take on the task of transforming an old school application into a domain I'd like some pointers as to how others have structured their aggregates - on a completely high abstraction level. I understand and respect others intellectual property, and as such, also willing pay for guidance if required. However the information I'm after here is very abstract at first - I thought it could be interesting to know your aggregates; not the behaviour details they contain.

Any reservation system would probably be interesting and car rentals or hotel accomodation in particular as that is our business. There should be no harm done, in deriving our approach on something that worked for someone else. Or as a minimum get some inspiration on what (not) to do when looking at general reservation/booking business behaviour. There are specific business values that are different of course, but most likely you would have the same core concerns, with much the same invariants as anyone else in that same business.

 

Anyone care to share on how they structured a reservation system? What aggregates did you end up with? How did words like "Reservation", "Customer", "Account", "Order/Invoice" etc. translate into aggregates?

 

Werner

[ashic]

Words don't translate into Aggregates. I'd recommend Vaughn's series
here:
http://domaindrivendesign.org/library/vernon_2011

There are many approaches to designing a reservation system based on
performance, scale and consistency requirements. Perhaps if you
explain your specific requirements, we may be able to chip in.

-Ashic.

On Feb 13, 2:01 pm, Werner Clausen <itempl...@hotmail.com> wrote:
> Hi,
>
> I wonder if anyone else here has developed a reservation system? Probably
> yes, and before we take on the task of transforming an old school
> application into a domain I'd like some pointers as to how others have
> structured their aggregates - on a completely high abstraction level. I
> understand and respect others intellectual property, and as such, also
> willing pay for guidance if required. However the information I'm after

> here *is* very abstract at first - I thought it could be interesting to

[Michael Brown]

I have a colleague who's doing a third-party booking system for resorts. After I introduced him to the Data Model Resource Book, he mentioned that Volume 2 had a model for hospitality verticals that was a huge improvement over what he had built on his own. I'd argue that's as good a place to start as any.

 

---

From: ddd...@googlegroups.com [ddd...@googlegroups.com] on behalf of Werner Clausen [item...@hotmail.com]
Sent: Monday, February 13, 2012 9:01 AM
To: ddd...@googlegroups.com
Subject: [DDD/CQRS] Examples for reservation/booking aggregate structure

[Peter Ritchie]

I haven't modelled a reservation system; but... Without knowing the behaviour the system is attempting to model, you can't appropriately define aggregates.

Aggregates are a means by which to group the entities and value objects involved in specific behaviours the system needs to perform.  As Vernon points out, this can be a means by which to maintain the invariants that these behaviours need to maintain between entities aggregated by the aggregate.

Without specifically knowing the required behaviour, you invariably inadvertently group by data; i.e. you come up with a data-centric design.  Data-centric may not be bad; but it hardly ever takes into account consistency rules and boundaries and you end up putting a lot of work into maintaining the consistency between the data "structures" simply to maintain data separation where you may never have needed to.

Cheers -- Peter

--
"Refactoring with Microsoft Visual Studio 2010": http://bit.ly/c13trs
http://PeterRitchie.com/blog/
http://twitter.com/PeterRitchie
http://facebook.com/Peter.Ritchie/
http://www.linkedin.com/in/PeterARitchie
Skype:Peter.a.Ritchie

[Werner Clausen]

Hi Mike,

 

Just to be sure - we are talking about this book yes?

 

Werner

[Werner Clausen]

 

I knew about part 1 and 2. Looking at the part 3 video as I write this.

 

At the moment I'm trying to get a birds eye view on how a new system *might* look like.

Examples are nescessary in all aspects of development.

 

Werner

[Werner Clausen]

Peter,

 

I understand all that. However examplification is a nescessary and important part of any developers life. You know this - why are we visiting "CodeProject" or "StackOverflow" websites  all the time? To see examples! To get ideas on how others have solved abstract or specific problems. Why should complexity define that examples are not nescessary? I completely fail to see that.

 

If you were develping a calculator application you'd still be interested in seeing examples on how others have solved that task right? Regardless of how your UI differs, and regardless that your calculator is going to be so much more advanced. Of course you want to see examples on how other calculators look and work.

 

And I understand the need to protect interlectual property - and willing to pay for it. But this community really needs more examples. Real examples on how to model ordinary business data. You say "Without knowing the behaviour the system is attempting to model, you can't appropriately define aggregates". But why do you assume that behaviour is so different from system to system? Even those systems that handles much the same invariants!? I totally disagree - in fact, if it is true, that all DDD/CQRS modelling are so different from eachother that there is nothing gained from looking at examples; then that modelling took the wrong turn somewhere, and got bloated and unnescessary complex.

 

Werner