Supporting The Show
If this episode was interesting or useful to you, please consider supporting the show with one of the above options.
Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.
I am your host, Jamie “GaProgMan” Taylor. In this shorter episode, I wanted to fix the ending for episode 90 (Clean Architecture and Subcutaneous Testing with Matthew Jeorrett). I had messed up the timing of everything in ending for episode 90, and wanted to supply you with a fixed version of the ending. I’ve already fixed the full version of the episode, and that should have updated in your podcatchers. But I wanted to give you a fixed version of the final few minutes as a separate file, that way you don’t have to re-download the entire episode to here the knowledge that Matthew had to share with us.
So we’re going to pick up where Matthew tells us that having zero dependencies in the My Booking Hub domain code made it trivial to add unit tests to.
So let’s sit back, open up a terminal, type in
dotnet new podcast and let the show begin.
The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository
Yeah, so it’s, there’s a web website in the film, the show notes. So if people want to check us out, and you can, you can click there and find out about or get in touch. And on the second point, so how was My Booking Hub? What what does it use in terms of all these ideas we’ve talked about? I think the key one was the clean architecture, kind of structure, project structure. So I kind of borrowed a lot like I say, from, from Jason Taylor, is clean architecture and set up the kind of three layers which he he describes the domain layer, which has zero dependencies, and it’s this crunchy business logic we talked about that is complex and important in itself, the infrastructure layer talks to the external world. So it connects to the database, it sends emails, handles, HTTP over rest. And then the application there fills in the gaps or hooks up the domain to infrastructure. And so that was that was kind of bedrock that we decided on very early on in My Booking Hub, and stood the test of time, when we’ve had new features come in to be developed. I’ve never had too much difficulty and understanding how it breaks down into those parts of the application into the architecture. For instance, the the algorithm that kind of crunchy but it does the clever appointment suggesting and one of the problems with the existing system, when we rewrote it was that was quite strongly integrated with the database and so to test that you had to hook up to a real database to write any tests against it. But with clean architecture, it became obvious that the Making it zero dependencies is, is what we need to do. And that would go in the domain. And so by making the algorithm zero dependency makes it super easy to unit test, you can just fire in models at it without having to worry about database connection and give us high coverage in that. We’ve tested all the edge cases and the complexity of that. So that was that was a really important decision. And I think it’s allowed us to understand going forward when we’ve continued to make changes to the algorithm and improve it.
Excellent. Okay. With all that said, if you were to give some advice to someone who wanted to create, either create from scratch or rewrite a system, using some of the techniques we’ve discussed today, the different types of architecture, whether it’s clean executor, monolithic microservices, whatever, and all the different types of testing we’ve talked about, and all the different things that you’ve talked about with my booking up, do you have maybe two or three pieces of advice you’d give to someone who’s looking to do that to sort of start from scratch? And are some of those pieces of advice? Go watch this video, go read this book? Or is it more a case of eight? Just make sure you get the fundamentals? Right before you start was? What are some of your pieces of advice?
Yeah, I think going and reading the Well, looking at the report from Jason Taylor, and he’s got many videos online, I think, can’t stress how excellent a resource that is. And so that’d be Advice number one. And I think the only other bit of advice I would give is, consistency over correctness. Once you’ve picked an approach, try and stick to that and don’t, don’t get lost in all, we can make this better. And we can do this thing differently. Try and set your principles early on, and then stick to them. And then concentrate on building a system using using that architecture, those principles, it’s very attractive to think, two months after you you’ve started your project and new validation library comes out or you feel you find there’s a better way to do validation. And so you start writing validation in a different way. And then people come into your project to see the same thing been done different ways. And it’s really hard to understand what’s going on. And I think something I keep on coming back to a lot recently is consistency over correctness, it doesn’t matter if it’s the best way of doing it. But if it works, and it’s the same as everything else, then people can understand that and it saves the hassle of just looking at code and thinking, I can’t understand this, I’m going to have to sit and go through this and load it all into my memory before I can start to do anything for it, the codes laid out in unexpected way. And it follows patterns. It’s so important.
Sure, and it saves on context switching as well. All right. So if there’s a chunk of code, if there’s one of these pie slices, that does things a certain way. And then you have to you finish the work on that pie slice, maybe you’re implementing a feature or fixing a bug, and you jump to another pie slice to do some other work. And it is it is the same code base is talking to the same business logic areas, filling in the same gaps where the application area is still got those connections to the outside, or the same things are in place. But everything works completely differently. Maybe you’d like to say you’re doing the validation differently, or maybe it’s a different type of authentication. Or maybe it’s a different database for no real reason other than it’s a different database. Not like I’m not getting at, like, you know, all this bits in in ASP .NET is identity, because that’s a good fit for this project. And this bit is in what I mean just like a completely different, right, this bit of the code talks to Oracle, because the person who wrote it had an Oracle license and is safe, we’re doing Oracle, right. The problem there is like you say you’ve got the context, which when I come to work on that second chunk of code, I have to a, get an Oracle license, be installed loads of software, and then C before I can even do that, I need to understand what the codes actually doing. So you’re absolutely right, I think I think consistency is more important. Because then you’ve got almost like a common language in the team. You know, the the whole idea of domain driven design is that you, you write the I’m probably going to mangle this I’m trying to sort of reduce it a lot. You write the dough, the program, and the logics which fits the domain of the problem and uses that common design language we talked about earlier. And then if you are doing things the exact same way, almost like coding standards, using the same libraries using the same sort of setup, then all the only thing you’re switching on is the part of the problem that you’re solving. Not Oh, and this bits written in VB or this bits written in Go all this bit is written in, you know, there is scope for that in other projects. But if you’re working on a single project that that is, and I’m not trying to say that My Booking Hub it was a small project, but if you’re working on a single project that has this pie slice idea, there’s a vertical first circles get vertical, the horizontal aroma and always have to my entire life, we’ve got this vertical design idea, this pie slice idea, then you would expect jumping between the pie slices, a lot of it to be not the same, but very similarly put together, right?
You say prettify, but that’s actually the name of the tool, I call them to prettify the name of the ticket was pretty funny on save, we actually put that in the front end recently. So that so that we get that function is it’s just modern tools like devs, doing their tooling for devs. And it’s all beneficial.
Yeah, for sure. So I don’t actually it’s one of the things that local renter a website, which people can contact me by LinkedIn, find me message and be more than happy to, to elaborate on any of the things we raised or just hook up with people. Yeah. Jason Taylor. His GitHub handle is Jason Taylor Dev, slash clean architecture. Hopefully that’ll be in the show notes as well. thing a completely different style of resource but one I always go back to is this website called the morning brew by Chris Alcock and it’s just a really good distillation of things that be happening. Kind of .NET, Microsoft focused with a little bit of React and Angular. And every weekday he posts around 10 articles that just give you a flavor of what the most recent things are. And anyone in the office who’s like, oh, they need to, firstly, .NET is getting released this week. How do they know that? One way you can do that is just who can, the more improved,
I have to say I used to use that quite a lot. I read on the train into work, and be on the phone, read through a few articles, bookmark a few get into work where you still work. As soon as we hit slack, right? Guys, you got to read these three articles, because they were amazing. And none of it is related to what you’re doing. But hey, check these out. This is where the the industry is going. Or, hey, you know, there’s this cool new feature coming to Xamarin or whatever. It’s a it’s a wonderful resource. It really is. So yeah, I can I can recommend that too.
Yeah, I’ll give you a beta of the links in the show notes.
Oh, absolutely. Yeah, everything we talked about will be in the show notes. So people don’t have to make this joke about. So you don’t have to if you’re driving into work, he doesn’t dive over the dashboard to hit the pause button. So you remember the time code for when you send it or anything like that. Everything is in the show notes. So don’t worry about that. But yes, I guess I guess Matthew, all that really remains to say is to thank you ever so much for being on the show. And and thank you for sharing your knowledge. And I hope that lots of people go check out my book and go and get in touch with you on LinkedIn.
Thanks very much, Jimmy. It’s it’s been a pleasure always always like talking tech.
Excellent. Excellent. Well, thank you ever so much.
The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository
That was my interview with Matthew Jeorrett about the Clean Architecture and Subcutaneous Testing. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.
And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/subscribe for ways to do that - reach out via out contact page, and to come back next time for more .NET goodness.
I will see you again real soon. See you later folks.