All models are wrong, but some are useful. This insight from George Box has become a cornerstone of software modeling. While exploration and experimentation are essential for shaping models, it is challenging to know when a model is wrong or when it has become obsolete. 1/5 youtu.be/EZTl9FH5AFQ...

Reading posts on linked in makes me realize that many people (specifically agile coaches) don't understand what we mean by "team autonomy".

When I first heard of Cynefin and Wardley Maps, I felt like it was stating the obvious. Some domains are less predictable than others, some technologies are less mature, and this should affect our decision process, not exactly groundbreaking.

🌟 Big news! 🌟 I'm thrilled to announce that @josianchevalier.bsky.social and I will present our talk on Model Mitosis for the very first time in the US at Explore DDD Conference in Denver (April 14-17)! 🇺🇸

A massive thank you for all your incredible feedbacks on our talk, Model Mitosis: Stop making the wrong choice between microservices and monolith at @voxxedzurich.bsky.social with @josianchevalier.bsky.social Check out our slides slides.com/julientopcu/... And our repo gitlab.com/beyondxscrat...

Organizations are scared of change because they are scared of failure. Not all failure is catastrophic, safe-to-fail experiments are the best way to learn.

This year's VoxxedDays were really insightful ✨ If I could recommend one talk to watch on YouTube, it’d be «Model Mitosis» by @julientopcu.com & @josianchevalier.bsky.social. While it didn’t offer new insights (for me), it’s a great summary of the monolith vs. microservices approach 👏 #VDZ25

Join @josianchevalier.bsky.social and I on Tuesday at 11:05 AM in Room 4 @voxxedzurich.bsky.social to explore a dynamic approach for iteratively splitting your business model, without getting tangled in spaghetti code or creating a dreaded “distributed monolith.”

We commonly use the building construction metaphor to illustrate software development. But a software isn't a building, it's a garden.

Models are tools designed to solve specific categories of problems. Just as you can't replace a toolbox with a Swiss Army knife, you can't build effective software around a single model.

We don't work to get the best outcomes for our products. We work to stay busy. Sometimes, the best thing you can do is... nothing.

The push to define processes in most companies stems from fear and the need for a false sense of control.

"Startups need to write code quick and dirty to find their market fit. Take on technical debt, and worry about paying it later. Software craftsmanship will come when the finances are stable."

The most valuable lesson I learned from working with @julientopcu.com is the difference between a model and its expression.

#DDDesign is not about tactical patterns and fancy architecture. It's about giving a F about the domain you're working with.

A good (socio-)technical architecture isn't one that anticipates every future evolution you can imagine.

In tech, we tend to reduce continuous self-improvement to technical watch.

Socio-technical systems naturally evolve toward their most stable state. This state is shaped by forces at play on this system. There are many types of such forces, including Conway's law, company culture, developer culture, automation, impedance mismatch between domain and tools.

The most common mistake when splitting systems is dispatching concepts in different bounded contexts. Bounded contexts define the boundaries within which a model is valid. So at its core, strategic design is about building the right models. #DDDesign #DDD

Where did we go wrong with microservices? Quite a few companies have gone bankrupt from the microservice hell, and countless developers are still drowning in it.

One crucial property to consider when designing a system is isolating parts that need to change frequently from those that have high change inertia. By change inertia, I mean the effort required to make changes in a system. #DDDesign

"𝘞𝘪𝘵𝘩 𝘩𝘦𝘹𝘢𝘨𝘰𝘯𝘢𝘭 𝘢𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵𝘶𝘳𝘦, 𝘸𝘦'𝘭𝘭 𝘣𝘦 𝘢𝘣𝘭𝘦 𝘵𝘰 𝘤𝘩𝘢𝘯𝘨𝘦 𝘰𝘶𝘳 𝘗𝘰𝘴𝘵𝘨𝘳𝘦𝘴 𝘵𝘰 𝘢 𝘔𝘰𝘯𝘨𝘰!" No one does that. Not one person ever. Okay, maybe a few. But honestly, what's the probability? Is it worth the efforts and overhead?

We use events in Event Storming for the same reason we use them in Event Sourcing. And the reason is not that it’s in the name. Events are symptoms of unfolding processes. Processes are hard to capture directly, but events give us glimpses into them.

“A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.” ― Frank Herbert, Dune (1/8)

When folks try to understand Domain Driven Design, I think they often miss some of the context that the book was written in. One piece of context the DDD blue book calls out is Responsibility Driven Design (RDD)

Most features I built in my career were nearly useless and brought no value to the final user. It takes time and maturity to understand that user stories and requirements are only a value hypothesis. Only the feedback from production can confirm or contradict that hypothesis. (1/2)