Presentation: PracticalDDD: Bounded Contexts + Events => Microservices

I'm currently working as a software architect at Particular Software, the makers of NServiceBus. As an architect, I guide clients to help review their design or proof of concept to see how they can build loosely coupled systems using both event-driven architecture and domain-driven design (DDD).

When I first learned about event-driven architecture, it completely changed how I think of designing systems. It was as if there was a whole new world out there. With DDD, I started to see the discipline of modeling and design to use the correct language and also to model the behavior more than the structure of things. When you start combining the discipline of DDD, and then use messaging or events as a way of communication, the systems that you design tend to be reliable and autonomous. I want to share this knowledge. Speaking at conferences is my way of contributing back to tech. I think hearing my experiences could help other people when they’re designing their systems.

Architects, team leads and senior developers. I’d say anyone that's passionate about trying to design reliable software. This is not a technology-centric talk but more focused on architecture. Use of c# in some slides is just to drive a point on the design disciplines.

Three things:

• As George Box expertly said, “All models are wrong, but some are useful”. When you're trying to solve a problem, your first go of the design or the model is going to be wrong and there's nothing wrong with that. It's how we evolve after that.
• The importance of collaboration with your domain experts. It's the constant learning from the domain experts and refactoring your current model to evolve that’s going to produce a design that’s flexible with the business needs.
• Strive to use events and messages as a way of communicating between your services. This style of architecture leads to autonomy, asynchrony and reliability. What you want is autonomous microservices.

The biggest challenge is getting the right people (domain experts, software experts, key stakeholders) in the same room to collaborate. There are techniques for collaboration with the domain experts, for example, event storming. Without proper collaboration, it becomes hard to try and understand the behavior of the business and the various constraints. If the constraints are not modeled well, then it has an effect on the software. Modeling software using post-it notes is cheap, building software and writing code is expensive. In order to truly understand the interesting behaviour bits you're going to have to talk to the business people.

But it doesn't have to be hard. There are conferences like exploreddd.com and dddeurope.com that are focused exclusively on DDD principles and teach you how to incorporate all of this, both the tactical side and the strategic side of DDD in your software systems to get value immediately. There are several user groups as well run by people that are passionate about DDD. If you’re passionate about DDD and don’t have a local meetup, you can start one. Ping me I’ll be more than happy to help you get started.