Finding your service boundaries - a practical guide - Adam Ralph

We know it's useful to split up complex systems. We've seen the benefits of modular deployment of microservices. Dealing with only one piece of code at a time eases our cognitive load. But how do we know where to draw the service boundaries? In complex business domains, it's often difficult to know where to start. When we get our boundaries wrong, the clocks starts ticking. Before long, we hear ourselves say "it would be easier to re-write it".
Join Adam for practical advice on discovering the hidden boundaries in your systems. Help tease out the natural separation of concerns in a sample business domain. During 20 years of developing complex systems, Adam has had plenty of time to get things wrong. Learn to avoid the common pitfalls that can lead us down the path to "the big re-write".

NDC Conferences

[awright]

I love the full circle nature of the talk. I'm sure it unintentionally happens often.

[jameshickey]

I think from 20:50 on was my favourite part. Very practical examples of how to model your domain by asking the right kinds of questions from business stakeholders.

[comarnicolodi]

Great talk, i had a lot a insights off it, thanks

[socceroos]

It strikes me that despite the warnings about the systems approach, some features are indicative of business boundaries changing - and at that point, I don't see any benefits of the bottom-up approach. Suddenly, you need to hack Mothra's corpse in half and give birth to Zeus, Hercules and Hades with Godzilla still chilling in the background.
Edit: especially obvious when a business needs to adapt to keep pace with a market disruptor. Oh how often the C-level exec laments that the 'approach' needs to change.