Should aggregate involve a read-lock in database?

Question

I read the Eric Evan's book about DDD, chapter Aggregates.

When dealing with the Order/OrderLine example, it is stated:

When both users have saved their changes, an Order will be 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 locked an entire Order at a time, the problem would have been prevented.

I well know that the essence of Aggregate is to protect invariants with a single wrapped database transaction.

But should every aggregate be specified with a read-lock at database side to prevent potential concurrency issues (race condition) while modifying this aggregate simultaneously by multiple users?

Is the real meaning of making an aggregate is to gather some elements for a read-lock at database side?

Any clarification about this would make me happy.

Answer 1

No, the two are orthogonal:

The goal of the aggregate design is to establish a consistency boundary and protect the invariants within that boundary. The goal of the locking design is to enable an appropriate level of concurrency within the application.

What this means is that with the same aggregate design, different locking mechanisms might make sense (depending on the non-functional requirements of the application).

Answer 2

I well know that the essence of Aggregate is to protect invariants with a single wrapped database transaction.

Is it? Aggregate roots are there as a consistency boundary around their own invariants. Given that persistence happens across a network in a completely different process, how can an aggregate in a process ever hope to guarantee consistency around something that is WAY outside its control?

The essence of DDD is separation of domain and infrastructure concerns; aggregates should be couched in terms of the domain modelled (Orders, Products, Customers) and everything else (databases, persistence, locking, transactions) are infrastructure and should not be polluting your domain model.