Speaking as someone having to deal with 1 state machine and 4 date fields to manage custom aspects of the state machine, the tech limitation is part of the state machine
@stephan well… consider this:
• we’re transitioning from a legacy system to our system gradually (a la strangler). Eventually all this work will be done in our new system (booking ads), and then, there won’t be a “booking” or “failure to book” (due to some external system’s rules).
• As we’ve explored the possible reasons why “booking” might fail, we’ve realized that they are all due to a lack of referential integrity in the underlying data (ads pull together concepts like property, supplier, buyer, etc). caused by allowing users to (in previous system) create and book ads from spreadsheets (Airtable)
• We’re almost certain we can avoid those data integrity issues in our current system, because the data is all managed via business rules (forms, controllers, models, etc)
• Our current plan is now changing from, Instead of asking the legacy system to book an ad, we’re going to consider it booked when the user requests it so… and then we’ll achieve eventual consistency and notify that legacy system of the new state change (since our data should be considered the source of truth).
• when that fails (legacy system doesn’t agree that booking is possible), we follow support channels to FIX THE LEGACY SYSTEM DATA.
Thus, I think we’ve just removed those states from the state machine, because they didn’t really belong to the business or the domain.
They were introduced because of a technology and a solution.