Does immutability argue of manufacturing data than storing it?

Question

I have seen an recent example of an Account domain model where the balance is calculated everytime from the transaction log fold left rather than having it as a state of the object. This is very good. But is it the core of immutability. (unable to tag the so answer here which put forth the design)

Answer 1

What you describe is a powerful technique for writing systems; it pretty much guarantees that the system will never lose data, and it means that programming errors will never "corrupt" your data - once a bug is fixed, the system returns correct results even for records that were added while the bugs were live. One useful technique (closely related to what's sometimes called "lambda architecture") is to treat this calculation as the "canonical" form of a given piece of information, but also provide a cache on top of it for efficiency - compare the database design where a database is denormalized to improve the performance of particular queries.

But it's not the only way to write systems with immutable data; for instance, you can apply updates as they're received, storing immutable instances of the complete Account with history pointing to previous versions (note that this may require the user to reconcile different "branches" if two people made changes at the same time - compare with using a VCS like git). This might be more appropriate for a system where it's very important to preserve exactly what the Account looked like at a particular point in time, and less important to preserve what the changes from one version to another are (e.g. I once worked on a system for dealing with insurance contracts).

"Is it the core of immutability?" is kind of a meaningless question. Rather than searching for "the core", I'd suggest looking for practical techniques that make your code clearer and more maintainable.