In the previous posts a simple mechanism of storing information needed for operation idempotence was introduced. A simple hash table, which state is transactionally saved with the state of object onto which the send operation was applied. How about receiving operations out of order? What if infrastructure (for instance, messaging system) will pass one operation … Continue reading Out of order commands
If you're in a startup and have a full-time job a the same moment as I do, that's a post for you. The initial startup pressure and tempo is huge. Focused on the features you can bring to life more and more of them. How often do you load your project, collapse it's whole structure … Continue reading What am I missing here?
Currently I'm involved in a greenfield project, which was happy enough to start as a event-sourced DDD. The paradigm fits well the domain, but there is some cost of zero-iteration which is being paid now. The cost is a small infrastructure which has to be provided to be wrap the domain. It's really small (maybe … Continue reading Features and unit tests
In the previous post a few operations were taken into consideration, whether there are (not) idempotent. For the sake of reference, here there are: Marked as default Money transfer '500$' ordered to 'x' account Label 'leave sth for the future month' added If we consider 'idempotent' as an operation which can be applied multiple times … Continue reading Idempotence, pt. 2
Recently, I've been reading a lot of dddcrqs group. The reason was a project I'm writing, which will be implemented in a DDD paradigm using CQRS and the event sourcing. As I read about about them, I found over one year old Greg's post considering pros and cons of idempotence. The definition of idempotence is … Continue reading Idempotence