I knew about time service before, but I did not know about freezing time per request, that's a great idea and I'll try to apply it in my projects. Thank you.
The first time I applied that design was in a project for a highly regulated market, where certain time frames were defined in the law (!), and having software that disobeys the time frame could cause our customers to be fined. We saw the problem while analyzing logs. Even though the external request did come to our Web service within the time frame, the database commit, according to logs, was milliseconds outside of it! There was no way for us to guess how long the transaction processing would take, and yet we did not want to cut corners. So we talked to the customer. It turned out that their company was acquired by a large player in the traditional media. They, in turn, were keen to see the project go smoothly and, by the same token, had political connections. Long story short, the media company talked to the parliament and obtained an official, legally binding response, that the time the law speaks of can be considered the time of the Internet request. Therefore, we implemented the freezing time service and, from that point on, all logs would display the time the request was received, rather than the time an actual externally-visible effect came to be. If anyone ever did an audit of our software, they would find that we did implement the law to the letter. One may argue that it was the first time that one software team had made the state build the technical concept of time freezing into the law!
Thank you, this is a gold mine. I literally had a similar bug, where a unit test would fail every year, because it calculated a difference based on current time, so every year I had to adjust the unit test data, or make a "buffer" and adjust it for a couple of years 😂
Very nice presentation and good explaination of the problem and the solution to solve the problem. I've not yet have to be dependent on a timestamp in the manner you're explaining it but I will implement it in a project very soon.
What's the best practice for implementing this in DDD Clean Architecture? In CA, the Domain layer shouldn't depend on any other layer. Usually a service like a DateTimeService would live in the infrastructure layer, with it's interface in the application layer, and the dependency injection for it is set up in the presentation layer. Hence my question is - where would you put the DateTimeService? Without making the domain layer dependent on other layers?
Domain would expose the interface, and so it would not depend on any other layer. Any layer can implement the interface, and implementation would be injected by the IoC container. Note that it is not a crime to provide a couple of useful implementations as part of the domain, so long as the implementation remains injected and models keep depending on the interface.
@@zoran-horvat That's brilliant, thanks for that, understood! I'm relatively new to CA and DDD and that was tripping me up today. Great videos, with a couple of gems in this one with the time freeze and checking that UTC Now has been used.
I don't plan to publish the source code - for a few complications connected with that. But if you focus on it, it is only a few lines of code that count - really, less than 10 lines of code! That is the beauty of this idea.
Do you do something with your uploads to turn on closed captions? I have closed captions turned off, but I always have to turn them off on your videos.
As a matter of fact, I do - all my videos have a tag included that turns CC on. I did that years ago, at someone's request. Do you think they are not needed anymore? I guess my English pronunciation has improved over the years. Maybe the time has come to get rid of that.
What do you think of a design in which the timestamp can be provided from the outside but defaults to DateTime.UtcNow if not provided? For example, the Borrow method in your example could have a DateTime parameter that defaults to DateTime.UtcNow. This might enable a feature like "retroactively check out a book that got carried out of the library without getting checked out at the counter". In such a case, would you also recommend defaulting to the DateTime provided by the ITimeService instead of DateTime.UtcNow?
That is the good point, though I'd rather separate time from the model state. Execution at specific time, whether in the past or in the future, allows development of truly powerful features. It is interesting to note that event sourcing supports that by design, which is a strong point in its favor.
@@zoran-horvat Yes, I actually had event sourcing in mind, as I am working with an event sourced system now in which a timestamp is a property of an event. We can set that to be any timestamp we like, but by default, it is set to DateTime.UtcNow. The challenge I see for this design with the ITimeService approach is that our events are simple records and we don't want to be injecting services into them. But for cases that are not event sourced, such as your Borrow example, I guess your response suggests that even if the Borrow method can take an optional DateTime, the default value should still come from an injected ITimeService. Is that accurate?
Become a patron and get access to source code and exclusive live streams: www.patreon.com/posts/dont-let-your-on-81382541
I knew about time service before, but I did not know about freezing time per request, that's a great idea and I'll try to apply it in my projects. Thank you.
The first time I applied that design was in a project for a highly regulated market, where certain time frames were defined in the law (!), and having software that disobeys the time frame could cause our customers to be fined. We saw the problem while analyzing logs. Even though the external request did come to our Web service within the time frame, the database commit, according to logs, was milliseconds outside of it!
There was no way for us to guess how long the transaction processing would take, and yet we did not want to cut corners. So we talked to the customer. It turned out that their company was acquired by a large player in the traditional media. They, in turn, were keen to see the project go smoothly and, by the same token, had political connections.
Long story short, the media company talked to the parliament and obtained an official, legally binding response, that the time the law speaks of can be considered the time of the Internet request.
Therefore, we implemented the freezing time service and, from that point on, all logs would display the time the request was received, rather than the time an actual externally-visible effect came to be. If anyone ever did an audit of our software, they would find that we did implement the law to the letter.
One may argue that it was the first time that one software team had made the state build the technical concept of time freezing into the law!
this channel is pure quality content, literally became a fanboy!!
any plans for merchandise? couldnt say no to zoran horvat sheets lol 😄
I knew exactly where this was going a few moments into the video. Now I think I have to implement this in my current project! 😫
Thank you, this is a gold mine. I literally had a similar bug, where a unit test would fail every year, because it calculated a difference based on current time, so every year I had to adjust the unit test data, or make a "buffer" and adjust it for a couple of years 😂
Now you know it!
Very nice presentation and good explaination of the problem and the solution to solve the problem. I've not yet have to be dependent on a timestamp in the manner you're explaining it but I will implement it in a project very soon.
I was just working on booking system and this video is as on point as it can get. Thank you!
Glad to hear it worked!
Ziveli! Zoki legenda :)
I guess it could be formulated that way, too ;)
Look into the IClock NuGet package (disclaimer: Author here). This does basically the same thing (and more).
What's the best practice for implementing this in DDD Clean Architecture? In CA, the Domain layer shouldn't depend on any other layer. Usually a service like a DateTimeService would live in the infrastructure layer, with it's interface in the application layer, and the dependency injection for it is set up in the presentation layer. Hence my question is - where would you put the DateTimeService? Without making the domain layer dependent on other layers?
Domain would expose the interface, and so it would not depend on any other layer. Any layer can implement the interface, and implementation would be injected by the IoC container.
Note that it is not a crime to provide a couple of useful implementations as part of the domain, so long as the implementation remains injected and models keep depending on the interface.
@@zoran-horvat That's brilliant, thanks for that, understood! I'm relatively new to CA and DDD and that was tripping me up today. Great videos, with a couple of gems in this one with the time freeze and checking that UTC Now has been used.
Hi, thank you for the Video. Do you have the source code?
I don't plan to publish the source code - for a few complications connected with that. But if you focus on it, it is only a few lines of code that count - really, less than 10 lines of code! That is the beauty of this idea.
👍
Do you do something with your uploads to turn on closed captions? I have closed captions turned off, but I always have to turn them off on your videos.
As a matter of fact, I do - all my videos have a tag included that turns CC on. I did that years ago, at someone's request. Do you think they are not needed anymore?
I guess my English pronunciation has improved over the years. Maybe the time has come to get rid of that.
What do you think of a design in which the timestamp can be provided from the outside but defaults to DateTime.UtcNow if not provided? For example, the Borrow method in your example could have a DateTime parameter that defaults to DateTime.UtcNow. This might enable a feature like "retroactively check out a book that got carried out of the library without getting checked out at the counter". In such a case, would you also recommend defaulting to the DateTime provided by the ITimeService instead of DateTime.UtcNow?
That is the good point, though I'd rather separate time from the model state. Execution at specific time, whether in the past or in the future, allows development of truly powerful features. It is interesting to note that event sourcing supports that by design, which is a strong point in its favor.
@@zoran-horvat Yes, I actually had event sourcing in mind, as I am working with an event sourced system now in which a timestamp is a property of an event. We can set that to be any timestamp we like, but by default, it is set to DateTime.UtcNow. The challenge I see for this design with the ITimeService approach is that our events are simple records and we don't want to be injecting services into them. But for cases that are not event sourced, such as your Borrow example, I guess your response suggests that even if the Borrow method can take an optional DateTime, the default value should still come from an injected ITimeService. Is that accurate?
@@cbgrasshopper I agree, the implementation from the video is typical of OOD.