My Intro to Domain Modeling with riffing: The Bike Shed & RailsConf talk
For the past many years, I’ve been heavily focusing on leveling up my domain modeling skills.
In my experience, domain modeling is the most overlooked part of software design, while at the same time being the most high leverage one.
Now my contention is that if you neglect upfront creativity in an exploratory design phase, you’ll be forced to be pay for it with rote processes to get yourself back on track.
Take refactoring, for instance. A phenomenally useful skill to learn, particularly when your codebase is in a bind. But also, how come it’s some of the only code skill content we have in the Ruby community?
And on the other end of the spectrum, we’ve got Domain Driven Design, a cool yet hefty tome to slog through. (Full disclaimer: I didn’t make it through.)
No Perfect Design
I keep feeling like there ought to be a better process out there, one that’s more fun and interesting too. One that lets us make better decisions, while allowing for and incorporating more perspectives too. Through exploring those different options we can detach more from the particular code we’ve written today and let go of (my) perfectionism.
There is no perfect design!
For me better designs is a better process for tossing ideas around; for getting your juices flowing so that you are in a safe space where you’re free to explore.
If you defer the need to be correct, for a minute, you can have ideas that you wouldn’t have in any other way.
Let me be clear: we absolutely need to our software to be correct. It is non-negotiable.
What I’m talking about is: how do we get there, and who are we being, to ourselves and each other, on the way there.
If we’ve given ourselves a hammer — sometimes a heuristic like Law of Demeter is used in this way — are we just boinking each other silly with them?
“You’ve made a train wreck!” and “You’ve violated XYZ”.
Fun times. I’m glad I’m on this team.
The Other Way is Riffing
All this to say that I’m finding a better way, bit by bit.
Riffing, is this term, I’ve been using to describe this alternate process.
I’m thrilled that the two best ways I’ve been talking about it are out now.
RailsConf talk
The talk is my best overall showing of what I’m going for with riffing and what I’ve gotten out of it.
There’s two live demos: a short one that I practiced and another one completely live.
The last one failed. At least, originally, I thought it had because I didn’t get the outcome I had in mind.
What actually happened, was people getting what I was going for and actually really wanting to chime in!
I, caught like a deer in the headlights from being on stage, couldn’t add 2+2 together, so it’s hopefully a fun watch 😂
I also think it’s important that those of us who are senior, show that we’re human and can’t always have the best ideas.
The Bike Shed
I recommend listening to the Bike Shed episode after you watch the RailsConf talk, just because we dissect that experience.
We also talk more broadly about Domain Modeling and meeting up in Chicago to do a riff together.
I hope it’s a fun listen!
I want to share more about Domain Modeling and my particular way of doing that with riffing.
There may be some more riffing videos happening in the near future. Is there a particular problem in a Rails app you’ve struggled with that you’d like to see us tackle? Stuff like how do I model payments and subscriptions correctly, how do I model email automations, or similar?
Also, if you have thoughts on this post, the others in the archive, or have something you’d like my take on: please do reply or reach out. There’s no dumb questions 😉