1

I'm fairly new to DDD and have been building a virtual airline app for flight simulators and I'm having trouble modelling the scheduling part of the app.

A bit of the domain details: first you start an airline, then you use your money to buy aircraft. Then you schedule flights, fly them and earn money. Any clashes in scheduling, either a double booked pilot or aircraft will not be prevented, but will be displayed to the user to get them to solve the clash. Same goes for if the aircraft is scheduled to be at airport A when a flight from airport B is scheduled to take place in in the same aircraft, you'd have to solve it by adding a flight from A to B at some point to make it valid.

So my question is how I would model the scheduling. I think scheduling should be an aggregate root, something like ScheduleWeek or ScheduleMonth but then I run into the issue of what if a scheduled flight spans two weeks? E.g. it starts near end of one week and ends after the start of the following week.

I've had a couple of thoughts, the first being that I duplicate it, so the flight would be in two schedule weeks, however I imagine I would need a saga for when a user wants to change the time of the flight as I would need to ensure both schedules are updated.

My other idea is that maybe I should model it as a moving timeframe, e.g. allow flights to be scheduled for the next 3 months and archive scheduled flights after they have expired, however this just feels like it might be an antipattern to me as flights would have to be removed. (I am using event sourcing though so they wouldn't be deleted completely)

Happy to elaborate on anything if anyone feels I haven't explained the domain or my ideas well enough. Also perfectly willing to accept I might have modelled this completely wrong and that there is a better model that what I'm considering.

Thanks

  • The database's implementation is separate from the DDD that interacts and represents the information stored in it. If you did have ScheduleWeek with a flight spanning multiple weeks and needed to update that Flight's time, there's no reason a single method call and a single database field update couldn't resolve it. Archiving, performance, etc are all separate concerns. – bitsoflogic Oct 5 '18 at 21:10
  • Thanks for the reply bitsoflogic, as far as I was aware, it's considered a bad practice to update two aggregates in a single operation, as the domain model is responsible for keeping the invariants satisfied. How would you go about that if they are backed by the same DB data? Surely only one aggregate at most would get to reject the command? Plus in my instance I'm using even sourcing so the DB data is necessarily separated as the events target a particular aggregate with a particular ID. I'm not sure that I understand how you would go about implementing that but I may have misunderstood you – Connor Wyatt Oct 5 '18 at 21:27
1

With these sorts of data modeling questions, I always go back to the source of truth, and stick with that until it proves unworkable (non-performant due to over-normalization, etc.)

In this case, assuming you're modeling the real world, the source of truth is:

Any given flight has both a start and end date, an aircraft assignment (e.g. N12345A or some other identifier), a pilot (probably an ID from another table), and whatever else your game/sim demands.

These records represent actual flights, either in-progress or scheduled for the future.

This is all separate from whatever planning system you want to add to the sim. For example, you might have a feature that lets you book a flight between JFK and LAX, on a Daily basis, using [Any Available Aircraft|Specific Aircraft], etc. Completing this form will then generate future schedule entries up to a certain max date.

You can then decide in the game if you want to resolve resource availability problems right then, or perhaps at the start of each "day".

But the key is that your actual schedule, and the mechanism to generate that schedule are separate things, with separate data models.

  • Thanks for your response. That's how I'm currently planning to model it, the actual flight information would be a separate aggregate and would contain the things unrelated to the scheduling e.g. the pilot ID. In your example what is the schedule? Is it an aggregate for all time, or am I assuming here that you think it's an aggregate at all? It's the structure of that resource that I'm struggling with and would be interested to hear your thoughts on how you would keep the schedule and mechanism separate. – Connor Wyatt Oct 5 '18 at 9:26
  • Oh I think I understand what you mean by keeping them separate now, are you referring to the fact that the scheduling mechanism is a consumer's concern? e.g. the UI, and the data model would just track it – Connor Wyatt Oct 5 '18 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.