Please log in to watch this conference skillscast.
We’ll start by exploring some aspects of time that require to understand the domain based on the example of Hotel Business.
1 - Time zones:
A user in Los Angeles books a room through our servers in Paris in a hotel in Sidney… A 3 day last minute discount could apply. When is it effective? What would happen for a hotel at the South Pole?
2 - Bi-temporal time:
Hotels define their prices and availabilities for each night. But to optimize hotel revenue, we use yield management technics, and look at how those values change in time: what was the price of the night of the 1st of august yesterday, and what will it be tomorrow? Having a clear understanding of the model is key to not get lost.
3 - Nights and days:
Hotels talk about the price for the 25th of June... but what does it mean? Most system implement it as a day. When Expedia started to permit people to book the 26th of June for the 25th, most people were surprised. Still a good understanding of the domain explains why it’s a total valid use case and most system model is to naïve. But what about when we'll book hotels on mars - different day length, year length ?
4 - Time passing:
Time that pass is hard to model in systems, language and APIs are far too naïve. By a careful understanding of how we feel time passing, we’ll see how events are a powerful model of time, and Domain Events with Event Sourcing tell the system whole story at the Domain level. Time left can be used to show how expressive and close to the Ubiquitous Language Event Sourcing in F# can be.
YOU MAY ALSO LIKE:
DDD, The Hotel Business & The Effects Of Time
Playing around with computers from his younger age, Jérémie Chassaing is involved in many projects mixing game, art, math and engineering. Full time architect at d-edge for more than 10 years, he works on domain driven concerns, architecture, and performance in the hotel business. He's the author of Crazy Farmers, an IRL board game and its online version.