Finding Service Boundaries with the Bounded Context Canvas
Details
What's the talk about:
We finally have an answer to the question: "how big should a microservice be?". And the answer is: This question has been closed as off-topic. Size is really not the first thing you should be thinking about when designing boundaries. It's probably the last. Size gives us almost no indicators about the quality of our service boundaries unless we are at extreme ends of the scale.
This would be a great time to insert my silver bullet solution, but actually the Bounded Context Canvas is quite simple and boring. We made a checklist of the most important things you should think about when designing a service, and we turned it into a canvas. We then made it creative commons and put it on github http://github.com/ddd-crew/bounded-context-canvas…. Over the past year we've been developing the canvas in the open as a community and it's currently version 4.
While the canvas is "boring", using it is fun. It reminds you to ask the important questions, and it tells you in a friendly voice "hey, the design of this bounded context has a few flaws you might want to consider".
The Bounded Context Canvas is no lone ranger. It won't magically help you find those perfect service boundaries. But when combined with a couple of other techniques like EventStorming and message flow modelling, it will set you off in the right direction and give you and your team a visual and collaborative way to design your service boundaries and interactions.
About Nick Tune:
Nick is a technical leader who embraces every aspect of discovering, designing and continuously delivering high-scale software systems to growing and leading highly-autonomous software engineering organisations. He has been a practitioner of DDD for almost a decade, and is the co-author of two books: Patterns, Principles and Practices of DDD (Wrox), and Designing Autonomous Teams and Services (O’Reilly).