Since balance is immutable, the amount will always stay at 0.
The assertions seem incorrect to me, and when you debit 20 USD, I suppose that you'd rather call it on the incBalance object.

Moreover, this code seems only marginally better than before. Granted: you no longer have a shared state, so code referring to the original amount will still see the initial amount (zero). But if you handle two deposits in independent threads, you are still in trouble: the immutable design does not help; and you need some central system which ensures atomicity of the updates of the data persisted in the store.

Good catch regarding the assertions! Copy paste FTW .. will fix in the next MEAP .

Regarding your observations on thread-safety, we have not yet addressed these concerns. The idea is to show that getting rid of the shared state enables you to perform safe operations (in this context debit & credit) without causing any ambiguity in the Balance abstraction. We have not yet taken care of atomicity of writes - but each Balance instance that you get after doing an operation is consistent. Thanks for bringing this up - I will add a note in this context.

The idea of how I wanted to model Balance has changed than what it is in the current MEAP. The next MEAP will address the modifications. Just to give you a heads up, here's what the latest version looks like. It's actually a Value Object as part of Account. And Account is now the main abstraction .. Here's Listing 1.4 from the unpublished version ..