Just as development should be iterative, software design should change when the context and our understanding of the problem evolve. As a software grows to solve more problems, it becomes less supple in its ability to evolve. Tensions arise within the business model of the software that struggles to stay coherent.

Eventually it reaches a critical mass and becomes a monolith of spaghetti code. How do we know when it’s time to modularize our software? How do we carry on the decision to split it into several modules or services? How can we handle the progressive differenciation of our business models while avoiding unnecessary coupling? It’s not as easy as a clean axe cut in the middle, finding the right boundaries can be tricky.

We would like to introduce the Model Mitosis, a dynamic approach used to split a business model into multiple ones that will get shaped and decoupled iteratively. Gain flexibility to choose better when to split into multiple services, and avoid paying the scale cost of microservices or becoming a distributed monolith.

Recording: https://youtu.be/VO6BSb52K5g

Slides: https://slides.com/julientopcu/model-mitosis-a-dynamic-pattern-to-deal-with-model-tensions

Repository: https://gitlab.com/beyondxscratch/model-mitosis

The microservices trend pushed many people to oversplit their software into multiple services, creating distributed monoliths. After a decade of microservices in production, the industry is taking a step back and realizes that splitting too soon will generate important scale costs.

On the other hand, undersplitting the software by stacking evolutions without a modularization strategy will end up creating coupling between all the responsibilities, turning the system into a legacy monolith.

Even though those problems seem different, they are two sides of the same coin: the business model should drive splitting strategies.

It is quite complicated to find a pattern which helps people splitting a model in place while they have to insure the stability and evolution of the application over the duration of the process. People lack heuristics to take decision to spawn a new model and patterns to decide on the boundaries of the system.
In the early stages of the split, the complexity is generally not sufficient to draw the boundaries without overlap.

Julien has first dealt with this problem in production while leading the Train Booking System of Expedia in 2016 and Josian has been working on such issues since 2021 at EDF (French national energy company).

After several years of experimentation, we found a dynamic pattern to split progressively while limiting the coupling between the emerging models. By combining strategy patterns from Domain-Driven Design, we coined the Mitosis Pattern (as an analogy of a cellular mitosis).

It is implemented in 4 steps:
- step 1: a system model grows, the need of a new model emerges

- step 2: the models are split while sharing some concepts into a shared kernel. There are some rules to respect in order to keep it under control.

- step 3 : as models grow apart and specialize, their boundaries get clearer and the shared kernel fades to the minimum (like a strangler fig pattern).

- step 4 : two models isolated from each other, potentially with an anti-corruption layer

This pattern as been presented during DDD Europe 2023 and received great feedbacks such as this one https://twitter.com/tpierrain/status/1666694640660017152?s=20.

This presentation is a livecode, with a storytelling and aesthetics inspired from the TV show the Mandalorians.

With the recent rise of the A.I., we decided to start the reflexion on what could be our relationship to A.I.s in the future as a side take of our talk. With the assistance of several AIs, such as MidJourney 5 and ChatGTP, we created illustrations for our intro and a fake speaking and coding assistant, to illustrate this reflection.