In one of the projects I worked on, there were a lot of actions that happened at specific times. At midnight the logs would be rotated, an hour past midnight things where rescheduled and checked. at a specific point in the schedule, that item was processed.
With Domain Driven Design it is not obvious how to implement this. Normally we don't have timers in the domain. First of all it is not easy to test timers and their events and secondly, it is not the responsibility of the domain to get the current time and initiate actions.
So how can we do it then? What I am about to write is something I didn't try, but it basically 'popped up' in my head.
A timer is in terms of DDD just an external service. Every time it needs to fire an event, or the time is changing, it will send a message to the domain. So basically it is like a heartbeat. (During my graduation we had a program which controlled a robot, and that program also had a heartbeat to let the robot make decisions...)
In the domain we can have classes like Schedule,which has a method that can receive the current date and time. When this method is called, the schedule will look to the scheduled actions that should be run at that time and will fire events to initiate the actions.
These events can go from one domain to another (bounded contexts, did I already speak about that? if not I will try to do that soon), or from one application to another. We can also store the events that come in and go out, so that we have a history of what happend.
How do the events look like? I think of them like normal objects that contains information about the actions.
I understand that the above is a bid abstract, but it came to my while I was reading different articles about Event Sourcing, Command Query Seperation and other things over the last view days, and now I had the feeling that I should put this in some sort of writing to remember it.