Domain-Driven Design: When is a Bounded Context no longer a Bounded Context?
I really got into Domain-Driven Design about 5 years ago, when my company was coming out of its Big Ball of Mud style of development. While I will not comment on the overall success of our endevour to completely slay the BBOM dragon, we did, with each revision of our understanding of DDD (and thus each new Bounded Context), get quite good at business and functional isolation.
Over the course of those five years, we went from our product being one big ASP.NET MVC 3 application which was the all-singing-all-dancing-crap of the world, to a collection of ten or more bounded contexts, some carved from the original monolith, and others growing organically out of business need.
This was satisfying for a long time, until it wasn’t. That five years of migration and clean-up was long and difficult, but ultimately it has seen our product grow into something infinitely better than what was there before.
So what was eating at me? As the solutions architect, why did it all feel somehow wrong?
When it comes to the scope of your domains, size matters
When we review a pretty standard DDD context map, we often see things not dissimilar to this
