Most applications which deal with presentation (rich client or web) of data implement some pattern which allows them to separate presentation from the data. Our industry doesn't mind slapping all of these together model-view-controller. Irrespective of whether they are exact or not but are extremely useful. The controllers are responsible of loading/saving the data, maintaining user session and navigation control (deciding which view to display next). While domain driven design patterns helps one in keeping the controller lightweight, often the navigation complexity gets overlooked and leads to defective presentation code as a result. In my experience this is biggest source of bugs in presentation layer, except may be for browser incompatibilities. Navigation code is generally peppered across different controller classes and when the duplication is noticed it is handled quite poorly using base controller classes, utility classes/methods like navigators, helper, utilities, manager devised to handle local scenarios.
Using Conversation State the navigation control becomes first class concern in your presentation layer. Conversation State is inspired by state machine, where the user session, user request (e.g. http request and cookies) and response data form the basis of navigational decision making. In most presentation applications the user representatives (product owner, business people, usability experts) are very interested in what happens in this part of the code. Conversation State, on smaller scale, should allow you to do what DDD allows for in handling business complexity.
Conversation State pattern is made up of context of execution and logic based on the context.