Using the Transaction Script pattern - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 326

The customer enters payment information (credit card information and billing
address). The system updates the pending order with the payment information
and displays the pending order with totals, tax, and charges.

The customer confirms that she wants to place the order. The system authorizes
the credit card, creates the order, and displays an order confirmation, which
includes the order number.

Each paragraph of this use case suggests several transaction scripts, including:
■ updateDeliveryInfo() : Validates the delivery information and creates or
updates the pending order
■ updateRestaurant() : Updates the pending order with the selected restaurant
■ updateQuantities() : Updates the line item quantities of the pending order

You can also determine a transaction script's parameters, which consist of user
input, from the use case. For example, the Place Order use case implies that the
updateDeliveryInfo() transaction takes the delivery address and time entered by
the user as parameters. The use case may also reveal additional parameters and
return values that hold the session state that is exchanged between the presenta-
tion tier and the transaction scripts. See chapter 3, which uses the same techniques
to design the domain model service for the Place Order use case, for the details.

9.2.2 Analyzing the user interface design

Another way to identify the transaction scripts is by analyzing the UI design and
defining a transaction script for each HTTP request. Furthermore, you can analyze
the data that is displayed on each screen to determine the data that each transac-
tion script must return and hence the DTO s that you must implement. For exam-
ple, figure 9.2 shows the first two HTTP requests for the Place Order use case.
The first request is sent by the user's browser when they enter the delivery
information. The presentation tier calls a transaction script to update the pend-
ing order and displays the list of available restaurants, which must be returned by
the transaction script. The second request is sent when the user selects a restau-
rant. The presentation tier calls another transaction script to update the pending
order and displays the menu for the selected restaurant, which must also be
returned by the transaction script.
For the details of how to do this and a more in-depth example, see chapter 7,
which uses similar techniques to design a POJO façade.