Lead Developer and Solutions Architect, I specialise in Event Sourcing, DDD and Event Driven systems. PHP and GoLang developer. Enjoys being a smart ass and having a nice whiskey.
Location
Ireland
Education
MSc in Computer Science, Trinity College, Dublin
Work
Lead Developer and Solutions Architect at Contractor
I think our resistance to immutability comes from our cognitive coupling to databases. We've trained ourselves to turn specifications into tables, and we gotten so good at it that we do it intuitively, without even realising we're translating requirements into implementations.
We end up viewing it as the way things are, rather than an implementation of our model.
I was able to break the spell by moving to Event Sourced systems, you see how useful immutable messages are and how they actually model the system, as opposed to a standard RDBMS system.
I like the idea in the Event Sourced community that mature models eventually become event sourced. That is, eventually, you want auditing and a complete history of how you got there.
Lead Developer and Solutions Architect, I specialise in Event Sourcing, DDD and Event Driven systems. PHP and GoLang developer. Enjoys being a smart ass and having a nice whiskey.
Location
Ireland
Education
MSc in Computer Science, Trinity College, Dublin
Work
Lead Developer and Solutions Architect at Contractor
I definitely agree. As the business matures you'll want a deeper understanding of what's actually happening, so you can optimise and improve.
As as aside, the current trend is to just mash reporting software/code into our apps to solve this problem, but it doesn't really work. Making your application event sourced is really the best way to solve it.
There are those that think ES is a bad choice at the beginning of a project, but I disagree. Our model has evolved extensively over the last year (radically) and ES didn't interfere at all, instead it made us think about what we're doing and forced us to keep things clear and consistent. I doubt I could say the same if we were building a standard CRUD/RDBMS app.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice, I'll be using that in future.
I think our resistance to immutability comes from our cognitive coupling to databases. We've trained ourselves to turn specifications into tables, and we gotten so good at it that we do it intuitively, without even realising we're translating requirements into implementations.
We end up viewing it as the way things are, rather than an implementation of our model.
I was able to break the spell by moving to Event Sourced systems, you see how useful immutable messages are and how they actually model the system, as opposed to a standard RDBMS system.
I like the idea in the Event Sourced community that mature models eventually become event sourced. That is, eventually, you want auditing and a complete history of how you got there.
I definitely agree. As the business matures you'll want a deeper understanding of what's actually happening, so you can optimise and improve.
As as aside, the current trend is to just mash reporting software/code into our apps to solve this problem, but it doesn't really work. Making your application event sourced is really the best way to solve it.
There are those that think ES is a bad choice at the beginning of a project, but I disagree. Our model has evolved extensively over the last year (radically) and ES didn't interfere at all, instead it made us think about what we're doing and forced us to keep things clear and consistent. I doubt I could say the same if we were building a standard CRUD/RDBMS app.