042 - Building better applications with Julie Lerman

August 18, 2020

Julie Lerman chats with Jeremy about:

  • Domain-Driven Design
  • Event storming
  • Julie's new Pluralsight course about building .NET applications on AWS.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.



Hello, and welcome to All Hands on Tech, where today's leaders talk tomorrow's technology. I'm Jeremy Morgan. Today I'm talking with Julie Lerman, who's a software coach, longtime Pluralsight author, Microsoft MVP, regional director, and Docker Captain. I don't know anyone who knows Entity Framework quite like she does, and today we'll talk about that, plus domain-driven design and building .NET applications on AWS. So let's welcome Julie Lerman. 


So, how are you doing today, Julie?


Hey, I'm great Jeremy. How about you, up in your mountain retreat home, I think?


Yeah, I guess you could call it that. How's your mountain retreat home?


It's doing great. It's beautiful out today.


Tell us a little bit about yourself and what you do.


Sure, well, I've been programming for a little over 30 years, maybe a lot over now. I stopped counting. And I've done various things over the years. And now what I do a lot of is coaching for software teams, just come in for---whether I go on site or do, obviously these days, remotely, just go in for like 3 days or a week or maybe do something across a period of time, where I just come in and help them with certain problems, architecture, legacy software, domain-drive design, etc. And of course I consider myself a translator, which kind of blends into my Pluralsight courses and also writing. So I really like to dig in and do that research and make the path easier for other people so they don't have to struggle as much. 


Yeah, I think translator is an interesting way to put it. That is pretty cool. How did you get started in tech? Was it something that you got excited about as a kid?


No, there was no tech when I was a kid. I'm really old. Well, there was, there was. I kind of just, you know, there was just this natural like, in terms of my career, there was kind of a natural progression into it. I joke that in my 30s I finally realized that I was a geek and suddenly high school made sense. Maybe they all figured out I was a nerd back then and I had no clue about it. But it really was just a matter of getting at a job. I was at a job, and there was like one computer in the whole company. Well, I should at least say that I did take one computer programming class, a Basic class, like in 1982 in college. So there was that. That was my whole education. But I did have a job where, out of a thousand people in the whole company, my boss had the only computer in the whole company, he was doing accounting, on his desk in his office. And within about a week, it was on my desk because I was just figuring things out. And it[00:04:46.672]

 just kind of blossomed from there. So it really was just a natural progression in that way.


Wow, nice. My mom was an accountant, and that was how I was brought into tech also. She had a computer at home, which was kind of rare at that time. My curiosity got the best of me to where I was going to this computer constantly, and pretty soon it was like she had to kick me off so she could get work done. I was just so enamored with this box and shining lights. It was an old 286. 


Yeah, and just figuring things out, and having agency over that. You know, learning that whole, like, I'm going to make this do what I want it to do. And I’m going to make it solve my problems for me.


How did you get started building Pluralsight courses?


That was kind of funny. I had just made an arrangement with Microsoft to do some little mini videos on Entity Framework, one of the early versions. Maybe it was even the first version, or maybe it was 4, which was the second version, called number 4. And like a day after we had finally come to an agreement, I had signed stuff, I was in Maine doing a user group talk, and Fritz Onion contacted me and said, hey, how would you like to, you know, have dinner after your user group meeting? And he said, we'd love you to do some courses. And he was asking me to do just what I had agreed to do with Microsoft, so I was like, oh, that's kind of a conflict, jeez. So Pluralsight and Microsoft worked something out so that this content that I created went to Microsoft and Pluralsight at the same time. And so then from then on, what I ended up doing of course was all Pluralsight, since, I don't know, 2009 or 2010. So it's been a good 10 years.


Yeah, I first signed on to Pluralsight as a customer in 2011, and I know that your courses were there because I took them.


Oh, cool. There were like, I don't know, 20 or 30 authors then. Like the first author summit I went to was just in their offices, and there were like 20 or 30 authors. Now there's---I do not know. I don't know how many, 1000, 1200, 1500? I have no idea. 


I don't know either, actually.


I'm just a little bitty goldfish in the ocean now.


What first got you interested in Entity Framework?


Well, that's actually kind of a funny story because I had always been interested in data access, and I had written some articles on ADO, I had written some articles on ADO.NET. And with ADO.NET, I had actually interacted a lot with the team. So when they were working on what became Entity Framework, they had a preview of it, like a little private meeting at TechEd in 2006, and I was there, so I got invited to it. So I was curious. I'd never seen an ORM before, even though they existed. ORMs existed. In fact, this was Microsoft's third time at bat with an ORM. So what ended up happening was, I was all curious about it and having fun exploring it. Everybody else ignored it because they thought, this is the third time. They failed the first two times. It'll never get released. Then it was released, and guess what, I was suddenly the worldwide expert in Entity Framework because everybody else had been totally ignoring it.


Well, that worked out pretty well.


Yeah, lucky me.


So what do you like best about Entity Framework. I know you mentioned ADO.NET, and that's what I like best about Entity Framework, is that it's not ADO.NET.


Or one of the 16 iterations of data access that we had to work with up until then. You know, interestingly, you might think I'm going to say something about one of the technical aspects of Entity Framework or how it makes---well, I of course would have to say it enabled me to forget SQL. I was never good at writing SQL anyway. So all of that, writing the queries and all of the repetitive work of creating objects and populating them and then figuring out what SQL to write, update, or the data bindings and datasets. All of that stuff is gone, and it's more focused---less focused on how that persistence is working. And I get to focus on my business logic. So that's one thing I love. But the other really interesting thing that is wonderful for me about Entity Framework is that Microsoft is really committed to it. Instead of saying, okay, we're done with that, and moving on to the next thing, they've really evolved it in major ways. So it's, you know, with EF Core, complete rewrite, modern software, you know, creating this great foundation that they plan to build upon as Entity Framework Core evolves. So I really think that the two of those are my two favorite things about Entity Framework.


So what can you tell us about domain-driven design?


Sure, I actually just hinted at that also, about the fact that Entity Framework lets me really not spend too much time thinking about how my data is persisted because I'm much more interested in solving my business problems and writing the business logic and dealing with behaviors in my system. And domain-driven design is really all about that. There are two key things in domain-driven design. One is this focus on the domain, the domain being, again, the business problems you're trying to solve with your software. But the other really important thing is about the collaboration with the domain experts. Not just saying, like, say it's a doctor's office, oh, I've been going to the doctor my whole life. I know what your software needs. I'll just get back to you when it's finished. But really collaborating with them, understanding the domain, and really focusing on the problems of the domain.


With domain-driven design, does that bring more of a feedback element into things, to where the people actually using the software would give you feedback?


No, it's not at that level as much as it is the whole design, like before you even get started, this deep collaboration to truly understand the business process, what the problems are you're trying to solve, etc., but even as you're architecting, really interacting with those domain experts. And because of that, the way you're building the software, even like the terms you use, they're more going to be focused on the domain and the language of those domain experts, not the language of the technologists. So it's not just like after the fact, getting feedback from them. It's really from the get-go. 


Nice, yeah, that makes perfect sense. What are some of the challenges with domain-driven design?


I think one of the biggest challenges is that it's kind of a fast topic, and getting a deep expertise of DDD is something that takes time and experience. And people really worry that if they don't understand it end to end that they can't possibly do it right. And one of the things I've focused on with writing and keynotes at conferences and talking to people is that there's so much amazing guidance in there that you can grab onto some of it and start taking advantage of that as you start learning more and more, learning and being able to implement some of the other great guidance in there. So DDD is not a pattern and it's not a set of patterns. It's really guidance and ideas.


Okay, so it's something that if somebody is just getting into it, they can use it. It's not a discipline that requires kind of going back and learning this huge, gigantic thing before even starting at something that can be implemented slowly?


Right. There are practices in there, and there's guidance within DDD that you can absolutely benefit from individually, even if you're not doing DDD yet. And I say "doing DDD" with air quotes. But there's so many great ideas, and you just can build on them and build on them and take advantage of more of those ideas and then start benefitting in a much bigger way when you're working on a project.


Okay, and are there some misconceptions out there about DDD?


Well, I think what I was just talking about is probably one of the biggest misconceptions, is that you really need to be an expert end to end and understand all of it before you can benefit from any of it. And I guess that's one I'm focused on because that's something I talk about a lot and work with my clients on a lot.


That good. So, yeah, maybe some folks that are hearing this might be tempted to jump in and take the leap if they know that.


Yeah, exactly. And you're probably familiar with the course, Fundamentals of Domain-Driven Design that Steve Smith and I did a few years ago. We've gotten such amazing feedback from it, and that course is still going strong, which is great. We're planning to update that. Actually, I just finished a course, and Steve's wrapping up some courses, and our next thing to do is, we're going to get together, and we're creating a new version of the course. The ideas in there and the guidance in there, those things haven't changed. But because we were showing code, we were using, like, I don't know, Visual Studio 2015 and an old version of .NET. So we're going to--the story doesn't change, although it has been a few years, so we've both learned things, so some new ideas in there as well. But we just need to make sure that it's using the current Pluralsight slide template and designs, and we'll use Visual Studio 2019 and .NET Core.


So is domain-driven design in a fairly mature state, or it something that's still evolving?


I love that question, because DDD's been around. The milestone is when Eric Evans published his DDD book, the "blue book," we call it, in 2004. So it's been like 16 years. Yes, there's definitely a level of maturity and expertise now among the DDD community and practitioners. But what's really interesting is that there are so many people who are really adding to it and evolving it and leveraging new ideas on it. And Eric Evans absolutely is behind that. He's encouraging that. It's a living idea.


Yeah, that makes sense. I think a lot of the disciplines in tech kind of operate that way, where there is no "we're done" type of point. It's just constantly---


Right, yeah, it's not a JavaScript library. So it's ideas and thinking and guidance. So ideas are only going to evolve and get better as more and more people invest in them.


Yeah, absolutely. So here's a topic that I wanted to talk about, and it's something that I know little to nothing about, and that is event storming. What can you tell us about event storming?


Oh, well, event storming is actually one of those ideas that evolved out of the DDD community. Alberto Brandolini is a very well known and very brilliant architect, more than architect, but I don't even know what to call him. He's brilliant. He's also hilarious, so if you get a chance to watch any of his recorded sessions, I highly recommend it. Alberto was working with a client, and he was having a really hard time with people, just trying to get everybody to help. Everybody's trying to explain to him who the business works, and everybody's got different perspectives, and he just was not getting a clear story. And it was getting really frustrating. And finally he threw his hands up and with his great funny personality and his Italian accent said, enough, enough, this just isn't working. So he said, all right, here's what we're going to do. He got a pile of stickies, like Post-it notes, and said, just everybody write down, all the things you're trying to tell me, just write them down on stickies, just all the things that happen that you know, the events, the things that are happening in your business process. Just write them down and just stick them on the wall. And that was how event storming began. It's also a fun read in his book. It's called Event Storming. So event storming, so it's brainstorming, but it's focusing on the events in your system, the events in your business process. Because the events are the truth of what really happened. Not, this is what we want to happen, but to really understand the business, where do you start? How it does work. So by focusing on the events you're focused on actual things, the truth, the actual things that happened. So we start with big picture, total chaos, exploring, event storming, where you just get a lot of people in the room, people from across the board who understand the domain, not just the programmers. You get some people who are from the technical end, and people from accounting, somebody from customer service, somebody from sales. So you get the people who really understand the domain in a room and get them to do this thing with stickies. You know, nothing's wrong. Just write these things down, let's stick them on the wall, and then you go through this process of, you know, this iterative process of kind of organizing it and filtering and trying to really understand not just workflow but what are kind of critical dividing lines between important processes that are happening? So what you eventually look for is something called pivotal events. And by defining those pivotal events between these processes, then we're able to identify, it's important in domain-driven design, it's called bounded context. So we've got these different chunks. So what you're doing with DDD is, you're taking a big problem and breaking it down into small problems. And the small problems are disconnected. We have ways of connecting them afterwards, but you focus on each problem individually. And so problems elsewhere, problems that are way down the line, don't muddle up your thinking and your problems solving of a particular area. That's another key thing about domain-driven design. Anyway, so event storming is a great way of getting an understanding of the business process, but also getting an understanding what these different areas are. And one of the interesting things also to be driving for while you're doing event storming is finding, really figuring out what the real problems are that you need to solve, because you might think it's something else before you walk into the room. Or the domain experts, each person from different teams might have their own idea. But then as they're all collaborating on this and sharing information, they might kind of all zone in on like, oh, my gosh, this is really big. Maybe we should be focusing on this instead of that new feature that is just kind of a whiz-bang, like, oh, my God, we're losing money on this.


That's great. And it sounds like that's a good way to kind of compartmentalize things and find relationships between things but kind of keep things compartmentalized.


Yeah, and calm everybody down. This is what I feel I do a lot with clients because they're like, but, you know, this is connected to this and this is connected to that. And I'm like, it's okay, let's just focus on this. So I love doing it. I actually did a session for Pluralsight Live a few years ago that was just giving people an idea of what event storming felt like, and half of what we did in a room that was not at all the right kind of space for doing it, was really crazy, but it was funny. Half the time we were actually doing an actual event storming session, so it was kind of fun.


Yeah, that sounds pretty cool.


Wild times in Utah!


That sounds great. So you just released a new course, Fundamentals of Building .NET Applications on AWS. What can you tell us about that? That sounds pretty exciting.


It was, because I had, up until this year, I'd never looked at AWS before. You know, I'm like, Microsoft, .NET, Azure, blah, blah, blah. And I have some friends who are developer advocates, not just at AWS, but they're on a team that's called .NET on AWS. And I was like, what? What is that? It's like, well, we totally support .NET. You can actually, you know, they have all these integrated services on AWS for .NET. So I started looking at it, and I was like, oh, that's cool, like, oh, this is, oh, you know, I had no idea. So I wrote some articles, and then the next natural step for me was to do a course. And the course is for people exactly like me. I've been doing .NET for a long time, for people who, maybe they're curious about AWS and they're .NET developers, so they can get a feel for that. So I've got an ASP.NET Core application. I'm using SQL Server, SQL Server on AWS. Who knew? And so I'm deploying the application into, well, it's called EC2. It's essentially like a virtual machine, so self-hosted. There's ASP.NET Core self-hosted running Kestrel. Then I take the application and I do it in a Docker container and then create Docker image, Dockerfile, blah, blah, blah, in Visual Studio. And then I deploy it to AWS, where it's completely managed, because they've got all kinds of container support. So there's a service called Fargate, which basically, all you do is say, okay, I'm deploying into Fargate. You tell it a couple of configuration things, and it takes care of creating the orchestrator. You have to create the images, and then it will suck the images up to AWS, and then it will spin up the containers, and it will take care of the load balancers and all that kind of stuff. And then this was also kind of a weird thing for me. I've done a lot of stuff with Azure serverless functions, so I'd never done anything with Lambda. But I didn't start learning how to build lambda functions, but they have this whole feature called serverless applications where you take an application and then a lambda goes in front of it, but their tooling creates the lambda function. So instead of just hosting the application and it's sitting there spinning up the bills, the charges, because you're using the resources, the billing is done the same way as serverless is, so only per request and then the amount of time it's churning away resolving that request and sending back the response. So that was really cool. So that's what I'm doing in the course. So I've got an ASP.NET Core application, and each module I'm doing these different things. So again, if you're just curious, who isn't, just curious to see what it looks like, or maybe you're in a company, you're doing .NET development and they're like, we also want to be on AWS or whatever. I still, you know, I love Azure, I love the cloud, I love AWS. It's not that I'm choosing between one or the other. I think it's really, really good to understand all the options that are out there. It was great to have my hands on, you know, actually play with it and see, and go, oh. I mean, there's a whole team. The whole team for .NET on AWS, they have APIs. There's this huge toolkit. When I say huge, I mean you can interact with many of the AWS services in a toolkit in Visual Studio. There's also a toolkit for Visual Studio Code and for JetBrains, Rider, and all these different IDEs. I just had no idea all that stuff existed. So of course I was like, oh, how does this work? What does that look like? What does this do? Oh, that's cool, oh, yeah, oh.


Yeah, I'm very curious about that because that's been one of the challenges in the past, is with the hybrid cloud environments, especially with a big organization where they will have their .NET and their Windows people working on .NET and Windows stuff. And then it naturally migrated to Azure as they went to the cloud. But then they have a Linux group over here, and the Linux group has been doing the AWS thing. And then all of a sudden, it's like, well, we need to start putting some of this together and consolidating some of these services. And so that's a huge challenge, and I think that addresses it head on.


So I'm still in Visual Studio. I'm still using .NET Core. I'm still building ASP.NET Core applications exactly the same way I always have, and I'm not changing my code; I'm just using the tooling.


That's awesome.


There are tools to take advantage of all that stuff. Yeah, so that was really fun. It'll be really interesting to see how the course does. This isn't an Entity Framework course. Of course, I'm using Entity Framework in there because it's a SQL Server database, so I'm using Entity Framework also. So yeah, it'll be interesting to see how people respond to it. So far, I've gotten both responses from people who are like, yeah, I've been really curious, but others who have said, oh, great timing, because I'm supposed to learn this stuff. 


Yeah, exactly. That's awesome. So it sounds like Amazon is actively innovating on this, from what I'm hearing, right? They're actively moving on---


Yeah, the dedicated team, dedicated resources, absolutely. Yeah, all of it was a surprise to me. And they're like, uh-oh, if it's a surprise to you, it's probably a surprise to a lot of .NET developers.


Yeah, definitely. So yeah, that's pretty cool. So speaking of Entity Framework, is there anything new that's happening with EF Core 5?


Oh, my gosh, yes. As a matter of fact, I am working on an article about it also for Code Magazine. There's so much happening with EF Core 5. I don't know how much you follow of EF Core, but 3.0, they did this major thing with 3.0. They said, just wrote this, Entity Framework Core, but they really wanted to make sure they could keep innovating on it into the future. So they bit the bullet for 3.0 and changed a lot of the underlying mechanics of how things work. Created a lot of breaking changes. They were really transparent about that. But what they were doing was setting up this foundation for being able to do future stuff. So it's so cool in EF Core 5 to see a huge amount of benefit already. Like, they're adding so many things into there now that they couldn't add before because of that foundation that they created with 3.0. So right now what I'm doing is, I'm exploring many-to-many. Because remember we had that magical many-to-many always in Entity Framework, and then it wasn't there in EF Core, and it's one of the most requested features. So there was a way in EF Core and 2 and 3 to do many-to-many, but it's not a lot of fun. But the team really was like, they were not ready to, they didn't want to just replicate how it worked before because it was this magical stuff and it was really limiting. So now they've implemented it for EF Core 5 in a way that is not magical and takes advantage of just normal features of .NET and also things that they built into EF Core, so it's able to take advantage of normal features in order to be supported. So it's not magical, and you can interact with it. You can customize how it works and do different things with it. So I'm starting to play with that right now. There's a lot. There's huge lists. And every year, as the team continues working on EF Core, they become more informative and more transparent. There are all kinds of pull requests now coming in from the community, which is really, really cool. And I may be out of a job soon in the feature because they're also a lot of work on documentation and starting to add in not just how to write this query, but putting in guidance. Like, you know, okay, you're working in Blazor, or you're working WPF, like what are our recommendations to really use Entity Framework well on that platform? So there's a lot going on. What's not happening though is that whole big breaking changes thing that was really the theme of Entity Framework Core 3, that's done. That's not happening again. There might be a couple of little ones. It's going to be really minimal. And I think people are worried about that, like, oh, my God, it's the first time the team has ever done anything that dramatic. But it was this big scary thing for them to commit to, but it's already paying off in EF Core 5.


Yeah, that has to be a tough spot to be in on a team. A lot of technologies have had to do that, from Python 2 to 3, and different C# versions, and PHP. All of these different technologies have had to say, look, we're going to break everything you have. But moving forward, it's going to be so much better, and you're going to like it. And there's a tense spot, so it's got to be tough as a team leader to determine when to do that, and then---


Yeah, yeah, I agree.


Take all of the backlash from it for a couple years.


Yeah, I'm glad I'm only the messenger.


Exactly. How can someone position themselves for success working with data or domain-driven design or any of the things that we've talked about?


Oh, well, go watch my courses, of course. Was that just a softball? Thank you. No, I have, my most recent courses, of course, the Getting Started with EF Core 3, which I'll be updating to Getting with Entity Framework Core 5, so I mean, that is definitely, if you want to get started with Entity Framework Core, that's why I created that course. And it's the same with the DDD course that Steve and I did, the fundamentals course. And as I was saying before, even if you watch that course today, if you're there, if you're just going to that course to understand domain-driven design, and we've had so many people tell  us, you know, we tried reading this book, we tried this, we tried that, and finally, watching this course really gave us the foundation by which now when we read the books and try these different things, now all that stuff starts making sense. So we worked really hard to explain it in that way. Like, look, instead of, you should understand all these things so we're just going to start there, we really backed up and just handheld people through really just understanding the basic, basic concepts that give them the ability to then drive in more deeply with more advanced resources.


So what does your learning plan look like? When something comes out and you want to learn it, how do you approach that?


I usually wait a little while. I do, you know, I kind of like keep an eye on it, think about it a little bit. But I jump in. I jump into the code because that is the best learning for me. I need to learn by fire. Is that what the phrase is?




I'm going to learn that fire's hot, not by somebody else's story. I don't believe anybody. I've got to put my finger in, I've got to put my hand right on it and then learn it myself. But then I share that with other people. So that's why I say I'm the translator. I need to experience it. So I really dive in. I love to understand how things are working under the covers. I love debugging and just digging in and really looking at the fine details of, okay, when I do this, what changes? Like really far underneath so I understand how things are working. Then when I have problems, I'm in a better position to solve them, too.


So are there any cool projects you're working on right now that you can tell us about, other than the ones that we've already talked about? 


Well, actually right now I really am focused on creating some new courses and writing and learning, learning, learning, like, you know, Entity Framework Core 5 and the new stuff coming down the pipes.


Awesome. That sounds great. If I'm ever traveling to Vermont near you, what's one place that I have to go to, or one thing that I have to see?


When everything's opened back up again, the Shelburne Museum is a super special place. They have collections of historical things throughout Vermont. Buildings, if somebody was tearing down a beautiful old schoolhouse from the 1800s, the museum would go and disassemble it and bring it onto the property and reassemble it. It's an amazing place. Yeah, it's really cool, like a living history place, in a way.


That is cool. All right, well, thank you very much for talking with me today.


Oh, it was a pleasure, Jeremy. Thanks so much for wanting to have this conversation.


Thank you for listening to All Hands on Tech. If you like it, please rate us. You can see episode transcripts and more at pluralsight.com/podcast.