Model Mitosis: Stop making the wrong choice between microservices and monolith by Julien Topçu

Model boundaries should be discovered through behaviors and responsibilities rather than just data structures and concepts

When encountering model tensions (where one concept serves different purposes in different contexts), duplicate and specialize the concepts for each domain rather than forcing a shared model

A shared kernel between domains should only contain truly common, stable concepts that mean exactly the same thing in all contexts

Anti-corruption layers help translate between different domain models while preventing contamination between bounded contexts

Microservices are only warranted when there are actual business reasons for separate runtimes - conceptual modularity can be achieved within a monolith

The HIVE pattern suggests starting with a modular monolith and only extracting microservices when justified by business needs

Model tensions are a sign of hidden domain boundaries - pay attention to concepts being used differently in different contexts

Duplicating code doesn’t necessarily mean decoupling - the important thing is having separate, specialized models for different domains

Shared kernels represent areas of uncertainty between domain boundaries and should shrink over time as boundaries become clearer

Starting with a Big Ball of Mud and gradually discovering boundaries through behavior is better than prematurely splitting into microservices