Domain-Driven Design: Tackling Complexity in the Heart of Software

2.
Sharing the database
. Multiple users are creating contention problems in the database.
3.
Multiple users will be entering and updating various POs concurrently, and we have to prevent
them from messing up each other's work. Let's start with a very simple strategy, in which we lock
any object a user begins to edit until that user commits the transaction. So, when George is
editing line item 001, Amanda cannot access it. She can edit any other line item on any other PO
(including other items in the PO George is working on).
Figure 6.5. The initial condition of the PO stored in the database
Objects will be read from the database and instantiated in each user's memory space. There they
can be viewed and edited. Database locks will be requested only when an edit begins. So both
George and Amanda can work concurrently, as long as they stay away from each other's items. All
is well . . . until both George and Amanda start working on separate line items in the same PO.
Figure 6.6. Simultaneous edits in distinct transactions
Everything looks fine to both users and to their software because they ignore changes to other
parts of the database that happen during the transaction, and neither locked line item is involved
in the other user's change.

---

Figure 6.7. The resulting PO violates the approval limit (broken
invariant).
After both users have saved their changes, a PO is stored in the database that violates the
invariant of the domain model. An important business rule has been broken. And nobody even
knows.
Clearly, locking a single line item isn't an adequate safeguard. If instead we had locked an entire
PO at a time, the problem would have been prevented.
Figure 6.8. Locking the entire PO allows the invariant to be enforced.
The program will not allow this transaction to be saved until Amanda has resolved the problem,
perhaps by raising the limit or by eliminating a guitar. This mechanism prevents the problem, and
it may be a fine solution if work is mostly spread widely across many POs. But if multiple people
typically work simultaneously on different line items of a large PO, then this locking will get
cumbersome.
Even assuming many small POs, there are other ways to violate the assertion. Consider that

---

"part." If someone changed the price of a trombone while Amanda was adding to her order,
wouldn't that violate the invariant too?
Let's try locking the part in addition to the entire PO. Here's what happens when George, Amanda,
and Sam are working on 
different
POs: