Please log in to watch this conference skillscast.

Time is a familiar, yet really fuzzy thing. And then we have to write software that deals with it!

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:

• Greg Young's CQRS, Domain Events, Event Sourcing and how to apply DDD (in London on 22nd - 24th October 2018)
• Fast Track to F# with Tomas Petricek & Phil Trelford (in London on 6th - 7th December 2018)
• F# eXchange 2019 (in London on 4th - 5th April 2019)