As developers we are trained to apply principles like SOLID, Unit Testing and DRY, are lured into adopting certain architecture styles such as Event Sourcing or Clean Architecture, and are influenced to move away from monoliths to microservices. The truth is that all of these have value, but all can be applied the wrong way resulting in the opposite effect.

I believe that understanding or carefully designing the internal boundaries of your code base is the key ingredient to prevent that notorious Big Ball of Mud. This is not a trivial feat, so in this talk I will show you why I believe the importance of boundaries and provide you with heuristics and examples to (re)design your own boundaries to end up with a healthy codebase, whether you prefer to keep that monolith or go for a microservices approach.

• Help find the unit of testing
• Help find the scope of a DI container
• Help find applying DRY with causing coupling
• Help determine when to use an abstraction and when not
• Helps to figure out which architecture to use where
• Code that isn't supposed to be reused doesn't have to be in its own class.