J2EE design decisions - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 57

Harry determines that the business logic for this use case is quite simple and that
he can implement it using the Domain Model pattern. He decides that he must
use an offline locking pattern because this use case uses two database transactions:
one to read the order, and another to change the status of the order. Table 2.6
lists the design decisions that Harry makes.

Table 2.6 Harry's decisions

Strategy Decision Rationale

Business logic organization Domain Model pattern Even though the business logic is sim-

ple, it fits with the existing domain
model.

Database access JDO Using the Domain Model pattern.

Concurrency Optimistic locking The use case updates orders, which

are shared data.

Offline concurrency Optimistic Offline Lock pattern The use case reads the order in one

transaction and updates it in another.
The cost and probability of starting over
is small.

Harry also forgets that the Order class needs to use an offline locking pattern.
Chapter 13 looks at the different ways of implementing this use case.

The Modify Order use case
Finally, Wanda is responsible for implementing the Modify Order use case:

The customer service representative selects the order to edit. The system locks
and displays the order. The customer service representative updates the quanti-
ties and the delivery address and time. The system displays the updated order.
The customer service representative saves his changes. The system updates and
unlocks the order.

After analyzing the use case, Wanda makes the following decisions. Because the
business logic is complex, she decides to implement it using the Domain Model
pattern. Furthermore, Wanda thinks that she can reuse a lot of the pending order
code from the Place Order use case.
Wanda also decides that she must use an offline concurrency pattern since the
business logic consists of multiple database transactions. Because it would be very