The Modern .NET Show

Episode 9 - Designing .NET Core Applications with Steve Smith

Embedded Player

Episode 9 - Designing .NET Core Applications with Steve Smith
The .NET Core Podcast

Episode 9 - Designing .NET Core Applications with Steve Smith

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Steve Smith is a Microsoft MVP, renowned author, and one of the early members of the ASP Insiders, a group of trusted individuals that provide feedback to Microsoft on design direction. He also has a weekly podcast, Weekly Dev Tips, which provides five or ten minute long episodes that describe a single tip that can make developers better. Steve Smith also contributes frequently to the ASP .NET Core documentation and (at the time of publishing the episode) is in the top five contributors.

Smith was a guest on the podcast, and discussed many topics related to application architecture and design patterns in ASP .NET Core. He recommends that developers focus on one or two patterns and get the ideas down before moving on to others. Smith also recommends using the Strategy pattern as it is built into the ASP .NET Core framework and is a form of dependency injection. He also encourages development teams to create a monolith application that is modular first and can be split up along different feature lines before attempting to split it into microservices.

Smith also recommends that companies start with a small project as a learning experience before moving on to larger, more mission-critical projects. He suggests that developers read through source code and larger code bases to learn how design patterns are used. Overall, Smith highly recommends deliberate practice and experience to gain mastery of the patterns, and eventually reach a level of expertise where the patterns can be recognized and applied without having to look them up.

For more information on Steve Smith and his projects, listeners can follow him on Twitter, listen to his podcast, and sign up for his newsletter at ardalis.com.

Episode Transcription

Hello everyone and welcome to THE .NET Core podcast - the only podcast which is devoted to:

and not forgetting The .NET Core community, itself.

I am your host, Jamie “GaProgMan” Taylor, and this is episode 9: Designing Your .NET Core Applications with Steve Smith. In this episode I interviewed Steve Smith about design patterns, and how you can leverage them in your ASP.NET Core application. Steve - also known as Ardalis - has been a Microsoft MVP since 2002, has published numerous courses on both PluralSight and DevIQ, and runs the Weekly Dev Tips podcast. He’s an entrepreneur and offers mentoring for teams and individuals who want to develop better software.

So lets sit back, open up a terminal, type in dotnet new podcast and let the show begin.

Jamie

First off, Steve, I want to thank you for agreeing to be on the podcast. It’s very gracious of you to spare some time for me for this. So that’s very kind of you. Thank you ever so much.

Steve

No problem.

Jamie

For the very small Venn diagram of listeners who don’t know who you are, would you mind giving us a bit of an introduction?

Steve

Sure. So, my name is Steve Smith. I go by Ardalis online because Steve Smith is a disturbingly difficult username to find variations of at various online sites. I am a Microsoft developer. I’ve been writing software professionally for over 20 years, which means I’m old, and I’ve been working with .NET since the very beginning, before it was released. I’ve been very excited about .NET Core, which is sort of a rebirth of Net. I’ve contributed quite a bit to the ASP .NET Core documentation and written some ebooks for Microsoft on architecture. And you may also find me on Pluralsight, where I’ve published a number of courses as well as on DevIQ. I have my own podcast called Weekly Dev Tips, where I have five or ten minute long episodes that simply describe one tip that can make you a better developer. And my main thing that I do these days is provide mentoring and coaching for individuals and teams who want to develop better software.

Jamie

You obviously have a lot of experience and a lot of knowledge backing you up. So aside from obviously Steve Smith being a very common name online, do you mind sharing where Ardalis comes from?

Steve

No, I don’t mind.

So I’m something of a gamer and I used to have more time for tabletop role playing type games, but these days when I find any time, I’m usually just on an Xbox. But years ago I played games sort of like Dungeons and Dragons. There was a game called GURPS, which is a role playing game, and I had a character and he needed a name, and I made something up and I came up with Ardalis, which was just a name that sounded like a fantasy character name or something. And he was a paladin in this game that we were playing for a few years. And so I use that as my online name for early computer games like Diablo and things like that, and eventually just started using it as my online username because again, it’s really difficult to find S Smith, Steve Smith, Smith S anywhere and to have any kind of consistency. Whereas Ardalis, I could get the domain name, I could get the Twitter name, I can get the GitHub name, and if you’re listening to this, please don’t register that name anywhere so that it will be there for me when I finally get to whatever platform comes out next.

Jamie

I like that. I have a similar set up on some systems. I go by gapprogman, G-A-P-R-O-G-M-A-N. Right. And that goes all the way back to, I think I was at university at the time and I was studying games development and one of my friends who isn’t a developer said to me, “your superhero name could be Games Programmer Man.” Because we were all nerds at the time, I suppose I still am and it just sort of was birthed from that. In your biographical ar ardalis.com it mentions a whole bunch of stuff and I mean, you mentioned a whole bunch of stuff earlier on. You said work with Microsoft, 20 years of experience, all these kinds of wonderful things. It says that you were a founding member of the ASP Insiders. Could you tell us a little bit about that group from when you were there?

Steve

Sure. So the Microsoft ASP .NET team has had a great relationship with the developer community for decades at this point. And so this group goes back for almost 20 years, you know, 15 years or so, and has basically just an invite only group of folks that provide feedback to Microsoft on design direction and things that they’re working on. It’s become somewhat less relevant now since Microsoft has moved to open source and GitHub and we have Twitter and social media. So it’s a lot of the conversations that typically would have happened on an ASP insider’s mailing list ten years ago. Today is happening on Twitter, or more often, on a GitHub issue, which I think is great that Microsoft. Has become more open. But this group still remains sort of a group of known trusted individuals that Microsoft can go to if they have a question on something or some feedback they want to get from a smaller, closer group of non Microsoft people before they send some messaging out more publicly.

Jamie

I see. Moving on to your weekly Dev Tips podcast. You’ve mentioned it earlier on the design. I guess the aim is to spread some knowledge and help to make developers a lot better at their jobs. Was it literally that that sparked the idea ofF? What was the genesis, I guess, of of that that podcast?

Steve

I’ve been interested in the idea of podcasting for a while, but I’d always been, I want to say overwhelmed by the thought of trying to record over an hour with a guest and a cadence of something like .NET Rocks, which puts out at least two shows a week and always has different guests and things and has intro music and all this production quality that I was always intimidated by. And I found a couple of years ago a podcast from Jonathan Stark who’s got a podcast called Ditching Hourly. That’s really nice.

And it was a whole different format that I’d never heard before in a developer podcast. His isn’t really a developer podcast, but, you know, his first episode, his first podcast is like a minute and a half long of just him introducing himself, and then the next couple after that are like less than ten minutes, and they’re just describing some certain simple thing. And I was like, “oh, well, I could do this. I mean, five or ten minutes, that doesn’t take that long.” I mean, producing it, scripting it, editing it all that. It still takes over an hour. But finding an hour a week to do a podcast seemed from the outset something I could manage. Now it turns out I’ve been doing the weekly Dev Tips podcast for over a year now, and I’m currently on episode 26 or so, I think. So it’s more like maybe biweekly, but weekly is at least a goal that I have, and that’s kind of the genesis for it was just another way to reach an audience where they’re consuming content.

I’ve also seen that as cars become smarter, they’re starting to support podcasting directly inside the dashboard. And I think as that becomes more ubiquitous, more people will choose to listen to podcasts on their commute or on longer drives because it’ll just be easy, whereas up till now it hasn’t necessarily been as easy.

Jamie

I agree with you about listening to podcasts during commutes. I do that all the time because I’m an auditory learner, I can sort of switch off. I’m usually on the shuttle or on the train or something like that, so I’ll just sit there and sort of switch off and just listen to whatever it is that someone wants to teach me. So I tend to take it in a little better rather than just being entertained. So that works out well for me, I suppose.

Steve

Sure. And it’s a different format I’ve learned in doing the podcast, I’ve learned that there’s different ways to present information when all you have is voice and you can’t show a diagram or show some source code like you can in a blog post or in a video. So that’s been an interesting experience for me, as well as just learning how to present information in a different format.

Jamie

Sure, yeah, I can imagine that it would be different from giving talks as well. And I suppose it would maybe make the awareness of the audience better, sharper, I guess.

Steve

Maybe, I don’t know.

Jamie

Just really quickly. So the weekly Dev Tips podcast, is it technology agnostic or is it specifically about .NET Core stuff?

Steve

It’s pretty agnostic. I mean, I think if you listen to it, you could probably guess after an episode or two that I’m pretty much a .NET person. But these are not .NET tips, these are general programming tips. And so I think even if you were coming from a Java or PHP or whatever other background, hopefully you would get something out of some of them and if not, they’re short, so you can just jump to the next one and see if you like that one better.

Jamie

I see, that makes a lot of sense. I tend to agree with you, I’m a .NET developer myself, but going and reading some code in Java or in Dart or Go, regardless of the syntax, it’s still putting across the same sort of idea. So there’s always something you can take from someone’s description of some code, even if it’s not in a language that you usually use.

Steve

Yes, and I think there’s value in seeing how programmers solve programming problems in different languages and on different platforms and what problems they’re facing that maybe aren’t a problem in the platform that you use because it just gives you a different perspective.

Jamie

Sure, definitely.

Okay, so you mentioned it earlier on that you contribute a lot to the ASP .NET Core documentation. I actually looked it up just before recording and you’re in the top five. It’s, you know, that’s quite impressive, I’ve got to say.

Top 5 Commits to the ASP.NET Core documentation repo

Steve

I’m only in the top five? I was the top one for a while there. I haven’t done much in the last year and a half or so, but for a while there, before it was even released, I was writing a lot of the content and most of the stuff that’s in the fundamentals section was originally authored by me, although a lot of it’s been updated since then with the newer versions. That was a lot of fun and that was something I did to really help me learn ASP. .NET Core. There’s no better way to learn something than to be able to teach it. So I have a course that I did on ASP. .NET Core that’s published at DevIQ and I wrote a lot of the documentation again so that I could make sure that I really knew the stuff in order for me to be able to teach others how to use it. So that was stuff I did as a contractor for Microsoft. For the most part, I have contributed some stuff just for free as an open source contributor, but most of those article content items that I wrote from scratch were done on a contract basis from Microsoft. And that’s why for a while there, I was contributing pretty heavily and a lot of original content was because I had that relationship with them.

Jamie

Would you recommend that listeners go and have a look at issues and pages on the ASP .NET Core documentation, maybe have a look, see if there’s anything that they can contribute? I can appreciate that you haven’t looked for a while, but would it be the case that it’s pretty much feature complete?

Steve

It’s definitely not feature complete.

Yeah. I would certainly encourage folks to look at the documentation. I would start at the documentation itself on docs.microsoft.com or docs.asp.net and see perhaps where there’s places where they could add something. Sometimes it’s as simple as a typo. And if you want to really quickly get some PRs or some issues in there with your name on them, just do a spell check on the page or do a search for something simple like “the the” that happens frequently. And you’ll be able to find some bits of copy that you can fix up.

In terms of how to get your contributions accepted. The best place to start is by creating issues or participating in conversations on issues and then offering to help if there’s something that you think you could add. Always better to make an offer to the team through an issue you and through a comment than to just create a PR and submit it unless it’s for something really trivial. I mean, if it is like a typo that you’re correcting, just you probably just send a PR for that and they’ll probably accept it. But if you want to write your own article or if you want to heavily edit an existing article or add another example, that’s something where you could create an issue and then show them what your work is after they’ve agreed that’s something they want you to do because otherwise they may already be on it. They may already have one of their team members working on it.

Jamie

It’s better to try and ask to help out rather than force your contribution onto someone.

Steve

Yeah.

Jamie

Especially if you haven’t read the guidelines or anything.

Steve

Right. And I think that’s just general open source etiquette too. Right. Usually you want to have an issue that’s already out there that someone has seen and said, “yes, I think we should fix this,” and then volunteer to be the one to do it before you do the work, unless it’s, again, something trivial.

Jamie

Switching it up a little bit. You’ve also written an ebook on application architecture for Microsoft called Architecting Modern Web Applications with ASP, .NET Core and Microsoft Azure. Would you be able to tell us a little bit about that book?

Steve

Sure.

So this is something I did after I was pretty much finished doing the documentation work. I got a different contract with Microsoft to write this ebook and it’s sort of a clean architecture/domain driven design approach to writing, maintainable applications using ASP .NET Core and of course Microsoft Azure, if you like. Although all the all the principles and things that are in the first ten or so chapters of the book apply regardless of where you might host the application.

So the book is a free PDF, it’s in a couple of other formats too. It’s even just available online on the documentation site and it’s about 130 pages, I think. And it covers the basics of architecting things in ASP .NET Core. It covers some various principles. It covers testability and how to write tests for ASP .NET Core - both unit tests which are pretty standard regardless of whether you’re using ASP .NET or not, but also integration tests that will use the test host that ships with .NET Core to do integration testing and test the full stack, including things like routing and filters and things like that, which Unitests can’t easily cover in an application.

Talks about some design patterns, mostly domain driven design style patterns. So these will be things like repositories, specifications, uses dependency injection, the strategy design pattern throughout, so it results in loosely coupled code that follows the SOLID principles and basically is an application that you can extend and maintain fairly easily, can test it easily and you can swap out different components easily. So that if today you’re working with a particular data storage technology and later on you want to shift that to do something else, maybe you’re switching from local SQL Server to Azure Cosmos DB. You can make that change without having to rewrite the whole application or having to touch every single controller because it’s using a component-based architecture. And so that was a lot of fun.

And there’s a companion book that goes with it that basically is the same type of thing but using a micro services architecture.

Jamie

There’s also a GitHub repo called E Shop on Web, isn’t that? Is that correct?

Steve

Yes, that’s right.

The E Shop on Web sample goes along with my ebook and it is an example ASP .NET Core application of an online shop and it sells T shirts and coffee mugs and it’s a very simple online store experience as the sample. The companion site, the microservices site is the same domain. It’s also this online shop but built out using docker containers and microservices. And its sample is called E Shop on Containers because it uses docker and it has, for instance, a different microservice for authentication and a different microservice for showing the catalog of items and a different microservice for managing your shopping cart and a couple of others, I believe. And so you can kind of compare and contrast. Like, “here’s how I could deploy an application as a single monolithic web application using E Shop on Web. And things are relatively simple. It’s just a few projects that work together, it’s a single thing to deploy. But if I want to see how to really scale this out and have a more scalable application that leverages microservices,” you could then kind of see what the E Shop on containers architecture looks like and it’s significantly more complex because there’s a lot more moving parts. But there are some benefits that you can get from that if your application needs some of those features.

Jamie

I do like the idea of taking a monolith and splitting it into microservices, but obviously you’ve got to get the design of the monolith right first. If you’ve got one project to rule them all, taking that monolith and splitting it up is not going to be the easiest task in the world, sort of thing.

Steve

Right, exactly. That’s my recommendation for clients is that they create a monolith application that is modular first and can be split up along different feature lines but still run in the same process. And then they can take some of those feature lines and split them off into microservices, if it makes sense. But if you try and start off with microservices, you’re going to go slower and you’re probably not going to get those lines right from day one. And you’re going to end up with an application that is probably less performant and probably requires more maintenance time than if you had just built a monolith and let it evolve into a microservices architecture. As you learned more about the domain.

Jamie

That seems to fall in line with a lot of advice that I’ve heard at different local-to-me conferences. So obviously I’m over in the UK and I’ve been to a few meetups and talks and conferences where people are talking about, “here’s what we did wrong with Micro services.” And it always seems to be a case of, like you said, “we went straight for microservices and messed it all up from the beginning.”

Steve

Yeah, it’s like any buzzword, right, folks are going to get overzealous about it and try and apply it and that’s healthy to some extent. That’s how you get experience, that’s how you learn what not to do. The unfortunate thing is that people are doing this with their production applications, with their company’s money, so I’d rather they experiment. If you have the time on a private project or play around with something like the E Shop on Containers sample that you can just fork and play with, it would be a lot less costly that way. But it’s not always the developers making that decision. A lot of times It’s senior management has bought into the Koolaid and is saying, “oh no, everything must be microservices now. Last year it was SOA (System oriented architecture), this year it’s microservices.”

Jamie

Definitely, yeah. And I can’t even imagine how monumental of a task that would be, say, for someone who’s coming to say ASP .NET Core as a new technology. Maybe they’ve worked in Java Spring or maybe they’ve used Django before and they come to ASP .NET Core. And are told, “you also have to learn Containers and you have to learn this and you have to learn this and you have to learn this just to be able to start the application.” I totally agree with start small and build up.

Steve

Right, well.

And even if you’re coming from .NET, I .NET Core is fairly new and there’s a huge number of .NET developers that are less than six months or zero experience with .NET Core. And if they’re writing a new application, starting a .NET Core for the first time, a lot of the times that’s at the same time management is saying, “okay, great, now that we’ve got .NET Core, it’s cross platform, we can use docker, we can use containers, we can use microservices, we can use the cloud.” And so they’re adding all these things to their first project and their development team is like, “okay, I’ve never used the cloud before, I’ve never used containers before. I just learned .NET Core last week.” And there’s nothing that they have as a basis of experience and a track record of success to build on. And that’s not setting up those teams for success. It can work, but often times it’s going to take a little bit of time for them to learn all these different technologies and how they go together. And companies just need to realize that that’s the case and hopefully start with a relatively small project that can be used as a learning experience before they move on to the super mission critical rewrite of the mega application that the company needs to move to the cloud.

Jamie

I do remember, I think it was last year, there was a lot of chatter, I think on Twitter, I think it was from the Azure team, “let us help you to do lift and shift operations and let us help you to do shift to microservices and containers because it’s not easy.”

Steve

Right.

Jamie

So how about design patterns then?

So obviously you have a lot of experience of building different applications and presumably at scale as well. So we’re not just talking, “oh, I’ve built this web API and that’s my 20 years of Hello World,” because obviously you wouldn’t be in this position if you had done that.

With modern development, is there at the moment a great massive requirement for learning all the possible design patterns? Or would you recommend that, say, if someone is new to development and maybe they’re still at school learning, maybe college, university or maybe at a code [boot]camp or learning in their own time, is it worth just focusing on one or two, like, say, the strategy pattern or the command pattern, and just figuring those out first and then knowing that the others exist? Or is it worth going, “right, I’m going to get gang of four and I’m going to work my way through it.”

Steve

I would definitely do the first thing that you said, which is pick some that seem like they’re being used heavily in industry today and kind of get an idea that the other ones exist, at least know that these terms are design patterns. So if someone’s talking about singleton or flywheel or repository or whatever it might be, you should at least know as a developer, as a professional developer, that that is a design pattern so that you know that you can go Google it and find out more about it.

There’s a design pattern library on pluralsight that I’ve contributed to that has over a couple of dozen different design patterns that can kind of get you up to speed pretty quickly on any given pattern. I think most of the modules in there about half an hour, and it’s not going to make you an expert, but it’ll at least give you a good basis on what this pattern is and then actually show you how to use it, how to apply it. So I’d recommend that as one resource. And of course, there’s a ton of resources online if you don’t have a pluralsight subscription or you don’t want to grab a trial.

I don’t know all the design patterns. I speak at conferences and I do trading classes on design patterns. I don’t know every design pattern. I don’t think anybody knows all the design patterns. And developers find new patterns from time to time as well. I won’t say all the time, but it’s not that uncommon, especially when you move into a new way of doing things. There’s going to be docker and microservices and whatever new way of building applications we have. There’s going to be design patterns in those spaces that we haven’t discovered yet, or we haven’t codified into something with a name yet. And that’s all a design pattern is. It’s a common solution to a type of problem that developers have used often enough that they’ve decided it’s worth giving it a name and sort of codifying it in that way.

Jamie

Okay, so it’s a little like development languages and frameworks then it’s worth knowing that there are others out there that you can use, but maybe pick one or two and really just focus on those and get the ideas down. And then you can then transpose those ideas to the other design patterns. Or I guess languages. In my other example, you can then move to," oh no, I get how to do objects in C.++ Oh, cool. They work almost exactly the same in C#." Or “oh, this is how we do things in JavaScript and this is why we do things in TypeScript.”

Steve

Yes.

And a lot of the patterns, when they’re applied, at least the object oriented patterns, which most of them are, if there’s a pattern that’s being used in a class, generally the best practice is to put the name of the pattern on the class. So if it’s a repository for customers, data access service to get customers, it’ll probably be called a customer repository. On the other hand, if it’s a pattern that’s used to create customers, it might be called a customer factory or a customer builder. And factory and builder are two different creational design patterns that have different syntax and different assumptions. But if you know that those are patterns, then when you see in the code base that there is a customer builder or a customer factory, that’s going to inform you that, “okay, well, probably when I create customers, I should use this class because someone made this thing and obviously it’s got that purpose.”

And if you know those patterns, you’ll know how to use them as well. Like the customer builder, typically with the builder pattern, you’re going to call it and then keep calling it again and again and again. And each time you call one of its methods, it returns back an instance of itself. So you new up a builder and then you’d say, give me a customer builder and say .WithFirstName("Steve").WithLastName("Smith"), whatever. And when you finally set all the things you want to set through those methods, you call Build(), and it creates the thing and hands it to you. Whereas a factory typically you just call one method. You call it create customer or Create, and it just gives you back a customer. So it’s a little bit different syntax for accomplishing more or less the same task.

Jamie

So in that case, then that’s where reading through source code goes hand in hand with personal development. Is that the case? If you can track down a relatively large code base, the chances that someone has implemented a number of these patterns, maybe one, maybe two, maybe four, across their code base, the chance of them having implemented these patents will rise. And then you can read through the code base and go, “oh right, that class ends with factory, that class ends with command. This class ends with query. I’ll have to do a bit of research to figure out what these are, these common patterns, that kind of thing.” So I guess it would make sense then. Would you recommend that to read maybe not as much source code as you can find, but the larger code bases?

Steve

Yeah, it can definitely be helpful. And that’s another benefit of a lot of stuff being open source now, including ASP .NET itself. So you can go out to the GitHub repo for ASP .NET and you can do a search. GitHub has some great searching tools and you could say search for builder, search for factory, search for query, whatever the pattern might be, and you’ll find all the classes that have that name in it. ASP. .NET Core uses the builder pattern internally in several places, like to build configuration or to build the web host that your application is going to be hosted in. Those have builders that are named, wait for it, WebHostBuilder’ and ConfigurationBuilder’. And so those are pretty easy to find and pretty easy to use if you’re looking for an example of that pattern now, it’s not going to work. For every pattern, obviously, but certainly that’s a good way to see some real world examples of those particular patterns.

Jamie

Okay, that’s really cool. I feel like you’d have a little more experience with the ASP .NET Core source code than I do. The ASP .NET Core repository will have a number of different design patterns because like you say, use it to build a pattern for the web host and build a pattern for configuration. Perhaps there are methods out there that are using factory patterns and using all of the different strategy patterns and command and queries and things like that.

Steve

Yeah, I’m sure there are a bunch of different patterns. I’m sure they’re not all the patterns out there, of course. And some of the patterns are bigger than a single class. Like MVC is a design pattern model view controller. And ASP .NET Core uses model view controller pattern. But you’re not going to find a class that’s just something MVC. It’s a whole repository of MVC related types and things inside of the ASP .NET repo. So it depends on the pattern, whether or not it’s going to be confined to one class doing the work.

But overall, certainly looking at well established larger code bases is a good way to learn how these patterns are being used, along with books, blog posts, pluralsight, and other type of videos. I mean, there’s no end of ways that you can learn these things.

Jamie

Sure. And so I suppose you would agree with the general consensus then that there is no one design pattern to rule them all in the same way that there isn’t one programming language or one application framework to rule them all.

Steve

Yeah, there’s no silver bullet. It really depends on what the problem is and there may or may not be a pattern for any given problem.

Now, I will say that one pattern that I tend to use quite a bit and that is kind of assumed and built into ASP .NET Core today is the strategy pattern. And you won’t find very many classes that are going to end with strategy as their suffix because basically any service in ASP .NET Core can be used as a strategy because the strategy pattern is basically the design pattern that describes dependency injection. So if you’ve ever used dependency injection, you’ve used the strategy pattern and ASP .NET Core has dependency injection just built-in from the ground up. So when you build apps with ASP .NET Core and you say, “I need to register this service with the service collection,” and then you have some controller or something that asks for that service, you’re using the strategy pattern. That service is being injected using the strategy pattern.

Jamie

So when it comes to design patterns, then, is it a case of experience wins the day? Or is there like you say, there’s no magic bullet for a single design pattern that works? Like I say, is it a case of experience will win the day. Just by knowing that these patterns exist and having used the before, you kind of have a feeling that the strategy pattern works best here because I need to inject my dependencies or MVC works here because I’m doing something not necessarily on the web, but because I want to separate my models, views and controllers.

Steve

Yeah, I think obviously experience is huge.

When I give talks about design pattern mastery, I talk about the levels of experience, the levels of learning about a new topic. And you start at this level of ignorance where you have no idea that that’s even a thing. So maybe you didn’t know that with design pattern and called state and then someone mentions it on a podcast and you’re like, “oh, there’s this design pattern for managing the state of an object. I had no idea.” And so then you’re sort of at this awakening level where you’re like, “okay, I know that’s a thing, I could go learn more about it now if I wanted to.”

And then typically if you decide that you really like whatever it is, you get it to this overzealous approach, which I think is where a lot of developers and companies are now with things like microservices, for example, like we’ve already discussed. And this is where you’d just want to apply it wherever you can. You’re just looking for a problem where you can solve with this new tool that you have in your toolkit. And so you’re going to apply it probably more often than you should and you’re going to find places where maybe it didn’t work out as well as you had hoped. And that’s giving you experience, that’s teaching you, “here’s places where I used this pattern and it worked out great. And here’s places where maybe that wasn’t the best choice.” Eventually you get to this mastery level where like you said, you just kind of know you can recognize and see, “oh, I see this problem. I’ve solved this problem before, this kind of problem before using this pattern. And I don’t have to go look up how to do it necessarily. I do the pattern, I know what it is.” You’ve got this sort of muscle memory that you’ve developed through practice, either deliberate practice, which I think is great, or just experience having used it at work in the past.

Jamie

Okay, it’s a little bit like codecasters that by practicing certain techniques, like test-driven development or something, you eventually get to a point where it’s almost automatic.

Steve

Yeah, exactly. And I do a lot of that and I promote a lot of that. In our local user group, we don’t just have a speaker come and talk for an hour or an hour and a half like a lot of user groups do. We do lightning talks for the first half hour, 45 minutes, and then we do exercises together for the next hour and a half or 2 hours and everybody just brings a laptop and we pick a kata to do or go through a series of them and kind of pair up and work through it. And it’s a great way to learn different languages, different developers, approaches to things, or just practice the skills that you’re trying to improve yourself. And so things like that, whether you do it as a group or on your own, are one of the best ways for you to gain experience, in my opinion.

Jamie

So, a couple of final questions then. If you start a greenfield project, either a professional project that you’re being paid for or something that’s your own sort of personal private project, I guess the answers are going to be different here for either one of those types of projects. Are you tempted to just start coding and figure out the architecture and design patterns as you go? Or do you tend to spend a lot of time in the sort of planning process of, okay, so I need a login page and I need Entity Store and I need this, this and this and then that sort of infers the design as you go along.

Steve

Well, sort of because of my specialization with ASP .NET Core, most of the applications that I’m involved in from the start, either they’re my own, I’m probably building them in ASP .NET Core or they’re really simple and it’s a console app or if it’s for a client, it’s probably a new ASP .NET Core app for them. And I try and build those using a standard solution structure which we’ll call architecture, simply because that solution structure is something that’s difficult to change later and very important to get right at the start. And so I have a GitHub repository that’s ardalis/CleanArchitecture and it is basically the starter solution that I recommend and that I use for my own ASP .NET Core projects and for clients. And it’s very similar to the E Shop on Web One, but the main difference being that it doesn’t have a lot of stuff in it because it’s meant to be a starter template, not a sample.

And what that architecture does is it follows the dependency inversion principle. Meaning instead of having my user interface depend on my business rules, which depends on my data layer, which depends on my database, sort of traditional ntier dependency structure, it inverts the dependency between the business logic or the core domain logic in my system and the infrastructure that it uses, like the database or other services. It goes by several names. It’s clean Architecture is what it tends to be called these days, but it’s also been called Onion Architecture, Hexagonal Architecture, Ports and adapters and it works very well. So if there is one sort of architecture that I just kind of go to by default, at least in ASP .NET Core, it’s that. And then later on I might split that into separate microservices or things like that, but at least initially. The thing I want to get right is that I have a core domain model that I can unit test and it doesn’t have any dependencies on infrastructure like the database.

Jamie

Would you recommend the clean architecture that sort of clean oniony hexagonal architecture for people who want to move towards ASP .NET Core or would you recommend that developers figure out what works best for them?

Steve

If you are trying to get to a point where you can write maintainable systems that are unit testable and modular, I recommend that you at least consider some type of a project structure that follows the dependency inversion principle. It doesn’t have to be my template though that will get you going on the right foot, if you don’t have any experience doing it yourself. There are other approaches that can be successful. Another one that I see gaining traction is using Mediatr and using sort of little micro handlers for every different endpoint of your application. And if you go that route, you don’t necessarily need as much separation as what I tend to, but I think either one of those can work.

What I would encourage you not to do is create one big web project and put everything in that web project and don’t have any separation of concerns or any different logical structures or projects. And I also would encourage you not to make it so that your business rules end up having a dependency on your database or on entity framework or on web services or any other type of infrastructure. Because that’s going to make it much more difficult for you to maintain that code into the future and very difficult to unit test that logic, which is probably the most important logic in your application.

The one place where I’d say that that’s totally fine to just build a web app and not worry about it is if you don’t really have any business logic. If you’re just building a CRUD system, we got this internal system that has a database and doesn’t get used that often and every now and then somebody needs to go and add a record to this table. Sure, just build them a simple web page that lets them add an edit rows on a database table. Fine. But if you have something that actually has real business logic and it needs to be maintained for a while and it’s got critical business value to your company, you’re probably going to want to architect it a little better than that.

Jamie

Just sort of wrapping up. Where can listeners go to learn more about you and more about the projects that you’re working on and your podcasts and all these kinds of things?

Steve

Sure. So if people are interested, they can follow me on Twitter as at Ardalis I’m online as a blog ardallas.com. If you’re interested in the podcast, I have the weekly Dev Tips podcast. Is that weeklydevtips.com or just search for weekly dev tips in your podcast. App, and I have a weekly newsletter as well with different content that you can sign up ardalis.com/tips. And if you are interested in mentoring or coaching for yourself personally or your team, contact me through Rdallas.com as well.

Jamie

I’ll definitely have to put all of those links in the Show Notes for sure. It’s worth sending developers over there so they can check that out. I can say from my own personal experience that the Weekly Dev Tips Podcast is really good.

Steve

Well, thank you.

Jamie

You’re very welcome. I refresh the feeds on my podcaster. The first one that gets played, if there’s one, there, is the weekly Dev Tips one, because there’s always something that I wasn’t sure about or I didn’t know about at all, or something that reinforces something that I thought I already know.

Steve

So you would probably like it if I got those out more on a weekly basis than I have been.

Jamie

I can appreciate how difficult it is to put podcasts out on a very regular basis. For sure. I’m part of three podcasts.

Steve

Wow.

Jamie

Yeah. What’s this thing about free time? I guess all that remains to say is, thank you so much, Steve, for being on the podcast. It was a really great pleasure, and I’ve learned a lot, so hopefully the listeners will as well.

Steve

Great, thank you. I’m glad to have been invited.

Wrapping Up

That was my interview with Steve Smith. We covered quite a lot of stuff in this episode, so be sure to check out the show notes for a selection of links, and a collection of text snippets from the interview. The show notes, as always, can be found at dotnetcore.show.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice, and to come back next time for more .NET Core goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places