[Fixed Ending] Episode 90 - Clean Architecture and Subcutaneous Testing with Matthew Jeorrett
Embedded Player
![[Fixed Ending] Episode 90 - Clean Architecture and Subcutaneous Testing with Matthew Jeorrett](/logo.jpg){kind=logo}
The .NET Core Podcast
[Fixed Ending] Episode 90 - Clean Architecture and Subcutaneous Testing with Matthew Jeorrett
Supporting The Show
If this episode was interesting or useful to you, please consider supporting the show with one of the above options.
Episode Transcription
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
Matthew
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.
Jamie
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?
Matthew
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.
Jamie
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?
Matthew
Yeah. And it’s on a really fine, fine grained level as well. It’s not just about different languages and different database tools. But, but but different naming and different structure linting on the code, I think, linting people, people will laugh. And so it’s linting, like, focus on the important promise. But I think linting can actually make a code base much more reasonable, because anything that’s different in a code base catches your eye. So in JavaScript, like semicolons are optional. But if half the files have like, or some of the lines don’t have semicolons, and some do, that catches your eye, and it doesn’t matter in 99% of the day, it catches your eye, and it distracts you from what does matter. And so I think tight coding standards are important. And developers, like maybe think it’s part of their identity is how they read code. But I think it’s one of these things, it’s really about the team, doesn’t matter how you do it. A lot of the time, it’s about having that shared way of doing it. It should be a consensus. But then consistency over correctness, you do it that way. You don’t you don’t waver from that for all, for all good reason.
Jamie
Sure, it goes back to the idea of what works for the team, right? For instance, friend of the show, Zach, he says, I’ve had my last argument of linting, I’ve had my last argument over where the braces should go, and where semi colons go. For context, he used to be a JavaScript developer, he’s now moved to Python and things like he’s had his last argument to do with that, because the linter will take care of it for him. He’s got his ID set up. So he hits Ctrl. S, and the the, the coding standards are applied for him. So he doesn’t have to remember. So if he’s, if his personal, I am writing it in the flow, coding standards are that he doesn’t put semicolons on, he knows that when he hits Ctrl S, or Ctrl, you know, bang Q w or whatever, because he’s a vim user, he knows that when he exits out of that file and saves it, the linter will step in and do the bits that, you know, put the semicolons and rearrange air, but the brackets here and put this out, and then the other, and then he doesn’t have to think about it. He’s done the hard part of translating his thought into the syntax for the language. And then the tool comes along and sort of pretty fires it. I don’t want to I don’t want to reduce that. But he puts it into the right coding standards for that, that that team that he’s working alongside of. And I think that’s a it’s a very important thing to mention. I think things like editor config and linters are so important. And, you know, most of the IDS hook into these things and will do it all for you. And so I think is a great idea. I think you’re right, I think consistency, not just like you say not just the libraries we use the way we write it, but actually how the code looks when it’s loaded into your IDE. When you’re looking at the characters. That’s as important to like it.
Matthew
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.
Jamie
Yeah, excellent. I like it, because then it’s similar to oh, gosh, what’s it called, like our Babel and things like that. So you can write whatever version of JavaScript you want. And it will get transpiled down to a version that you know, you’re targeting ie So you ready with the error syntax? I’ll take care of the difficult bit of doing all of that wiring up for you. So you don’t have to worry about it. And yeah, it’s the tools, if the entire team writes with the arrow syntax, but yeah, but then you have to target IE, you’re going to have problems. But if you have a tool that sits in between sort of halfway, fantastic, you’ve got that consistency, it doesn’t matter if it’s correct or not. You’ve got that consistency. I like it. So, Matthew, right, as we come towards the wrapping up, how can people get in touch with you? What was the the URL for My Booking Hub again? And do you have any sort of top resources you recommend? I know, you said a lot. You’d say go watch our Jason Taylor’s videos and read some of his posts. Are there any others? You know, like anything? Just like, let’s help spread some knowledge, you know?
Matthew
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,
Jamie
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.
Matthew
Yeah, I’ll give you a beta of the links in the show notes.
Jamie
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.
Matthew
Thanks very much, Jimmy. It’s it’s been a pleasure always always like talking tech.
Jamie
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
Wrapping Up
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 our contact page, and to come back next time for more .NET goodness.
I will see you again real soon. See you later folks.