> Then again, sometimes your state changes not only don't need to be transactional; it can be disadvantageous to think of them that way.
I'm curious; in what kinds of situation would this apply?
> Depends, depends, depends.
Flexibility is usually an important requirement. Often you cannot freeze your architecture and be done with it. I think a transactional approach could better fit with this.
I'm curious; in what kinds of situation would this apply?
Any situation where the business value of having your state be 100% consistent does not outweigh the performance or implementation cost of making it so.
I'm curious; in what kinds of situation would this apply?
> Depends, depends, depends.
Flexibility is usually an important requirement. Often you cannot freeze your architecture and be done with it. I think a transactional approach could better fit with this.