About DDD
Be aware that "domain" does not mean the technical layer, like "UI", "business logic", "data access" or something like that. Domain means the business area and includes all technical levels. From UI, down to the database. DDD also recommend a technical seperation into layers. But thats happening inside a domain. So you may have a domain "order", which includes now all business logic and the UI elements around that business element.
About the logic
Let us think about an artifical example where your "order" can have 200 different states. Yep, quite artifical, but for me, using "extreme" examples help me to see some up- and downsides of solutions, which then could be also applied to real life situations.
Now with 200 states, having just one method "updateOrder" would need at least a switch with 200 cases (201 if you include a fallback default case). Thats.... ugly. We could then move the logic of each update case into its own method, which then validates if the update is allowed or not and does the state update itself. Still, a 200 case switch...
The other "extreme" situation would be an order with just two states. There the switch (or perhaps an if solution) is quite easy to read.
On the other side let us take a look at the state pattern.
200 states => we need 200 implementations (sounds ugly, but to stay truthy, we also would need 200 implementations of the logic in the above switch case). But each implementation is quite straight forward and only considers valid changes. That means, each state change implementation only needs to know those states that are could follow (to validate if the state change should be executed). The others could be ignored.
2 states => now the code is splitted in two implementations which makes it a bit harder to understand the whole state system, because we have to look into two implementations (just one for the switch case).
By the way "switch" does not mean that the "switch" logic is somewhere in the UI placed. I think it directly belongs to the state. Therefore i would create an order class which containes the current state AND the logic to change it.
And "state pattern" does not mean you have a "acceptOrder" and a "cancelOrder" method. There are just multiple classes (one for each state) which implements an abstract "updateOrderStatus" method. And the specific implementation then changes the state to "accept" or to "canceled". As a result the outside just have to call "updateOrderStatus" with the new wished state as a parameter, and the specific implementation of the current state does the magic.
That said, in my eyes it depends on multiple factors which design style to use. If the states will very likely NOT change and there are only very few states, then i opt for the switch version.
If the states are likely to change or there are quite some states (more then three or four i think), then i would opt for the state approach. Its easier to modify and for many cases easier to understand (at least what i think :-) ).
Now to the UI
If the business logic exports an "allowed state changes" function, the UI could ask the business logic which state changes are allowed and then show the appropriate interactions to the user (like multiple buttons, a dropdown, ...).
So it does not need to know the logic and does not need to "show everything", but only those things that are possible.
For me the important aspects are that UI and business logic are cleanly seperated.
Yes, the UI is dependend on the business logic, therefore if we change the business logic it may be that we also have to change the UI implementation(s).
But changes in the UI can not interfere with the business logic as such.
