It's okay for your UI to know some business process

It annoys me when people make arguments that the UI should have absolutely no connection whatsoever to the business processes of a system. To me, this is a far too crippling restraint. Is your UI also not supposed to know that a given process is going to update your orders, to look for a new one? Should you then implement some sort of back-and-forth chaining of events that ensure your UI is up-to-date, but have it take 10 minutes to get through the chain of commands, rather than happen instantly because it knows that adding an order will...add an order?

This kind of active UI - one that knows something of the business processes - is not the death of maintainability. WPF has made it somewhat easier to manage by implementing binding so effectively, but that also has its own problems. I would rather have my business commands handle the UI updates directly, but this can be quite a mess; better is to just have the UI, when it gets some signal from the user (or from anywhere) do the update itself, before or after sending the command to the business processes. You might send to the business processes before updating the UI, and have the command catch a response from the business process telling you if you should update the UI (maybe there's some problem that the UI cannot and should not be able to validate); conversely, it's also reasonable to just update the UI and send to an async business process if you know for a fact that the updating is valid, say because of all validation that has already taken place.

What you definitely should not do, however, is have your UI implement all of your business processes. This is not only not maintainable, it's simply downright pug-fugly.