3 ms·

See, this looks very logical, and a "command based UI" is great. But the diagram is missing _all_ the complex steps, that makes this type of system a lot of wo

by gnud 7y ago

See, this looks very logical, and a "command based UI" is great. But the diagram is missing _all_ the complex steps, that makes this type of system a lot of work to build and maintain. You need to be able to cancel. You need to be able to extend bookings, or change the room type. Sometimes, this will incur a fee, and sometimes not. In my experience (not from hotel systems), the operators _will need_ a way to actually edit the full state of the bookings. A registration form and a read-only 'booking view' will not cut it. I think it's a good idea to keep the "command-based UI" going for external/end-users though.

jonesetc 7y ago
At my job we have what I'll call an approximation of one of these command based APIs, looks like a classic RPC API. We also have a set of internal user procedures that are basically those escape hatches you mentioned. They are the source of almost every odd and problematic behavior we encounter in our normal API. I believe presenting slightly more open commands for internal use is the right idea, but sliding all the way to an arbitrary entity edit API is a quick way to break state expectations. Yes this could also be solved by having perfectly crafted constraints in the business logic and/or DB, but what's more manageable? Managing a few extra specific APIs, or having every expectation perfectly defensively coded?
joevandyk 7y ago
You would add commands for ExtendBooking and CancelBooking and ChangeRoomType, I think?
supahdup4h 7y ago
I think you are conflate not understanding context of how state needs to change vs we need to arbitrarily change state ad-hoc. The diagram isn't missing anything. It only describes the flows that it contains. This how I build all systems. It works. Nothing you've mentioned demonstrates a failure in this style of system design. I would suggest maybe there is a gap in your understanding?

by gnud 7y ago

jonesetc 7y ago

At my job we have what I'll call an approximation of one of these command based APIs, looks like a classic RPC API. We also have a set of internal user procedures that are basically those escape hatches you mentioned. They are the source of almost every odd and problematic behavior we encounter in our normal API. I believe presenting slightly more open commands for internal use is the right idea, but sliding all the way to an arbitrary entity edit API is a quick way to break state expectations. Yes this could also be solved by having perfectly crafted constraints in the business logic and/or DB, but what's more manageable? Managing a few extra specific APIs, or having every expectation perfectly defensively coded?

joevandyk 7y ago

You would add commands for ExtendBooking and CancelBooking and ChangeRoomType, I think?

supahdup4h 7y ago

I think you are conflate not understanding context of how state needs to change vs we need to arbitrarily change state ad-hoc. The diagram isn't missing anything. It only describes the flows that it contains. This how I build all systems. It works. Nothing you've mentioned demonstrates a failure in this style of system design. I would suggest maybe there is a gap in your understanding?