Key Takeaways
- When introducing DDD to a new team, start with bounded contexts – breaking down big problems into small, manageable, solvable problems. But leave out the terminology and just start doing it.
- Understanding the dynamics of a team in order to successfully coach them has a lot to do with instinct and empathy. It’s so important to listen carefully, be respectful, non-judgmental and to be kind.
- People resist DDD because they believe it is too much to learn or is too disruptive to their current process. Solving small problems is a good approach that can gain trust in adopting DDD.
- Domain modeling is an art, not a science, so it’s not uncommon to run into a wall and circle back or even have a revelation that makes you change direction. Teams benefit from encountering that with a coach who is familiar with modeling and is not worried about the perspective changing while you are going through the process.
At the 2017 Explore DDD conference, Julie Lerman, a self-described Serial DDD Advocate, spoke about how to approach Domain-Driven Design with Tender Loving Care. InfoQ sat down with Lerman to ask about how she introduces DDD to new clients, and helps them be successful.
InfoQ: Most DDD practitioners can remember how they were first introduced to Domain-Driven Design. What's your DDD origin story?
Julie Lerman: Mine is thanks to Jimmy Nilsson and believe it or not, InfoQ! Years ago, when Microsoft had released not one, but two ORMs (LINQ to SQL and Entity Framework) there was a bit of controversy going on. I came across an interview on InfoQ with Jimmy Nilsson where he was asked his opinion on LINQ to SQL and Entity Framework – an opinion I was very interested in. At the end of the interview, Jimmy was asked a question which I guess was asked at the end of all interviews ... "What is your favorite book?" His answer was Eric Evans’ Domain-Driven Design and Jimmy said that it read like poetry. Poetry! At the time I was writing a book for O’Reilly Press on Entity Framework. It was my first book and I really wanted to know what it meant for a tech book to read like poetry. So I picked up the DDD book and the very first discussion was about the importance of engaging the domain experts – something that had always been critical to my success with clients. I loved learning about their businesses and have built long-term, strong relationships with many of my clients. So that hooked me in! I thought that I had certainly found someone I could truly relate to in Eric.
InfoQ: DDD covers a lot of topics. When you start working with a new team, how do you introduce DDD for the first time, and how do you avoid overwhelming them with too many new concepts? Are there teaching techniques that should be avoided?
Lerman: I’m usually brought in at the point when either they are overhauling or replacing a legacy app or well under way. And I’m only there for a short stint, so I try to expose them to as much as I can, as quickly as I can. I start with bounded context – breaking down their big problems into small, manageable, solvable problems. And I don’t even start with the term. I just start doing it. Then I pick an easy target among the loosely identified bounded contexts and start analyzing it and identifying different parts of the domain model – one at a time, not all at once. And again, I start by using the concepts but not worrying about terminology right away. I know from my own personal experience that my brain locks up when I get the terminology thrown at me. So, I find simpler ways to introduce new topics – more obvious analogies. Eventually I add in the actual terms ... aggregates, aggregate roots, etc and explain that it’s important to use the terms so that everyone’s on the same page technically. That’s a great segue to ubiquitous language, too!
InfoQ: The subtitle to Evan's book is "tackling complexity in the heart of software." Conway's law would imply that complex applications often have complex organizations and teams supporting them. Do the concepts of DDD, such as Bounded Contexts, help with understanding and coaching a team?
Lerman: My approach to understanding the dynamics of a team in order to successfully coach them has a lot to do with instinct and empathy. It’s so important to listen carefully, be respectful, non-judgmental and to be kind. But I also lean a lot on my instincts and experience to help "read the room", so to speak. As a Libra, I’m all about balance and mediation. This has helped me a lot with clients when I’m working with teams and need to keep things moving forward, in a positive way. I think this ties back to the human side of the DDD equation – that whole aspect of working closely with your clients to understand their business, identify their problems and gain their trust in you to help solve those problems. This is what originally drew me to Eric’s book. The technical, or tactical design, aspect of DDD was just icing on the cake!
InfoQ: What are some common arguments you hear against adopting DDD? How do you respond to them?
Lerman: Some of the arguments are: Too much to learn. Too disruptive to our process. Will require too much re-thinking, refactoring, time.
And I draw back to the "solving small problems" approach – looking for opportunities to gain great benefit with a small investment. And it’s a good place to leverage their trust so they will follow along.
InfoQ: If you only have two or three days to introduce DDD and coach a team, what is your game plan? What are the goals, and how do you optimize the time to get the biggest achievement towards those goals?
Lerman: I first want to know what they are working on, what their goals are and what they are worried about – obviously something, or they wouldn’t have brought me in. Then I do the magical “let’s break this up into smaller problems”, pick the low hanging fruit among those problem and work on modeling it. As I’m most commonly helping with a legacy replacement, we’ll start modeling on whiteboards. And modeling is an art, not a science, so it’s not uncommon to run into a wall and circle back or even have a revelation that makes you change direction. It’s good for them to experience that with someone who is familiar with modeling and is not worried about the perspective changing while you are going through the process. I do some mob programming with them while I’m there for the same reason. I have a good idea of what technical problems we may run into so I can guide them through.
InfoQ: Any final thoughts for people trying to get started with DDD?
Lerman: While many people start their DDD journey by focusing on the technical software implementation (known as the tactical design), the strategic design is vital to DDD and comes first in the process as you work with the domain experts to learn about their domain and plan your system. Be sure to have at least a general understanding of the breadth of DDD, its goals, where it is useful and where it is overkill before diving in.
About the Interviewee
Julie Lerman is a Microsoft regional director and a long-time Microsoft MVP. She makes her living as a software coach and consultant to software teams around the world. You can find Lerman presenting on Entity Framework, Domain-Driven Design and other fun topics at user groups and conferences around the world. Lerman blogs at thedatafarm.com/blog, is the author of the highly acclaimed “Programming Entity Framework” books, the MSDN Magazine Data Points column and popular videos on Pluralsight.com.
