Isn't it redundant to store data in the domain and in the storage at the same time?

[budarin]

Why not transfer the data storage/retrieval functionality to the storage? The functionality for checking referral data integrity could also be taken out there.

This question applies in particular to state managers - is it worth duplicating their functionality in domain? After all, state managers are very closely related to the domain and therefore must be aware of referral integrity and other constraints in the data schema.

[bespoyasov]

It's a matter of trade-offs.

As I mentioned in the text, the example code is made intentionally purer than just pragmatic. If you have no objections against dependencies in the domain level, you're free to use a state manager inside the domain and build the model upon the state manager or another tool.

However, for a post that show the basics of the concept and introduces the reader into the idea, doing so would be incorrect and could raise a lot of questions.

Also, the domain doesn't store any data. The model here consists only of types and functions that transform data from one state into another. So there isn't really duplication of functionality.

I agree that it might seem tedious to have a dedicated domain model separately from managing the state but, again, for an introduction post doing otherwise, in my opinion, would not be a good fit.