What does the choosing consistency type "Ask Whose Job It Is" guidance mean?

Question

When discussing how to decide whether transactional or eventual consistency should be used in Part II of Vaughn Vernon's Effective Aggregate Design, he states

When examining the use case (or story), ask whether it's the job of the user executing the use case to make the data consistent. If it is, try to make it transactionally consistent, but only by adhering to the other rules of aggregate. If it is another user's job, or the job of the system, allow it to be eventually consistent.

I don't follow. Does anyone have a good example of applying this rule of thumb?

Answer 1

Here's how I get it :

• MovePiece() on ChessBoard aggregate => user's responsibility. The action should all take place in one transaction contained within the ChessBoard boundary.

• DecideGameOver() on ChessGame aggregate => system's responsibility.

  Some handler subscribes to ChessBoard's PieceMoved events and delegates to the ChessGame aggregate for it to decide if the game is over. We can tolerate a delay between the final move being made on the Board and when the Game aggregate is updated - it's eventual consistency.

It's not a hard and fast rule though, more of an indicator generalized from observation of dozens of systems.