How'd you like to listen to dot net rocks with no ads? Easy? Become a patron for just five dollars a month. You get access to a private RSS feed where all the shows have no ads. Twenty dollars a month, we'll get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey guess what, it's dot net rocks. I'm Carl Franklin, an amateur camp and we haven't it's been a while since we just recorded one. Last week's show
we recorded about an hour ago. But before that, it's been been a month because I went on the road for a month, all right. I did a couple of weeks in Mexico just to get out of the gray because it's the challenge of looking up up here.
And then NBC London.
I saw the posts you did from Mexico with our friends Paul and Stephanie.
Yep, they came. They came down for a week with us, and then I was at NBC London and then Sweet Dug in Stockholm.
Very cool.
So you saw Fritz there, I believe I did. The Fritzy was there, The Hunter was there, the Handsoman.
Wow, that's cool.
Yeah, I know the excess of Scots. To be honest, I will be at the other Stockholm conference dev some Yeah, I'm looking at being there as well, so maybe we can record some stuff.
Yeah maybe I think the weather be a little nicer when I'm there. Yeah, it'll be probably, I think just timing. Okay, let's get into better now a framework. All right, man, what do you got long last? Yeah, Music to Code Buy track twenty two is available.
Oh my goodness, it has been a while.
Is available for download and it's been added into the Election and the Wave collection and the Flat collection and you can go get it at music toocode buy dot net. Awesome, but that's not the only thing. Maybe should we play just a little bit of it?
Yeah?
You should, all right, I should go ahead, So there you go. It's just a little bit of it.
Awesome.
Yeah. So I do have an announcement around this whole music to Code by, music to Flow by whatever thing. So music to Code by, you know, it started long ago as a project that was on Kickstarter, did an album with three tracks and sent out a CD, and then I started making more tracks and selling them digitally and it all was going pretty well, and it kind of slowed down quite a lot, and then every once in a while, I'd throw out another track every year,
every couple of years. And I really wanted to market it outside of developers, because the developers are the only ones who know what music to code, buy is, and anybody else looks at that and says, I don't code, what do I need this for? And so I really wanted to market it as a you know, a relaxation, a focused tool to the broader audience. So I tried music to flow by. Well that didn't really work either, and so I'm rebranding it yet again, and it's going
to be called Magic Focus Music. Interesting, Yeah, because I think that kind of describes what it is. And I don't want to do this as an app. And here's why. I'm basically charging for access to this music, right And if you do an app, then you have to go through the app store in a purchases give thirty percent. What a what a racket that is? So I'm building a website. It'll be mobile friendly, you'll sign up, you'll buy your stuff. It's going to be subscription, it's going
to be affordable. And because I also figure that people are going to mostly use this like in their laptops, on their when they're working on their laptops, when they're on their desktop. So don't really foresee anybody putting it on on their phone while they're using their phone, because if he's in their phone, they're not really focusing on anything, are they true? Yeah, yeah, so that's the story. Look
for music tooflow by dot com. I will mention it on the show when it is available, but I'm working on it right now, and in the meantime, if you want to just download the tracks and manage them yourself, like most developers like to do, go to music toocoba dot net. It's the same stuff, all right, It's exactly the same music. So that's it.
Cool man, That's what I got. Who's talking to us today, Richard Grady Calm on Top of Show eighteen sixty one. We did it with Jeremy back in August of twenty twenty three. You know that I thought talking about minimal architecture. Hey, we're going to talk about vertical architecture, but first we talked about minimal architecture eighteen months ago. So Damien had this great comedy, said a great episode. I always enjoy hearing from Jeremy, and it's great to see. Finally a
tapering off of the micro services hype. I found much greater developer efficiency aggressively building natural quote seams that's seams seems into projects. Version one or the test edition might ship is a single process, but built from multiple projects, which can then be easily broken into deployal microservice if and when required. Another approach is to have multiple build versions of a product. One is a single process and
others might be split into multiple micro services. And if you get your seams right, the amount of additional work is trivial. It can be a good exercise which forces clean separations as a project grows and allows simple deployments and a fast develop when the mega load volumes are required. I find it useful to actively try and separate development from ultimate deployment. The vast majority of our business code can run just as well on a watch as in
the cloud. Although obstensibly ridiculous, I don't know watch based development approaching AI. Yeah, well, of course you'll have.
To have a cy my coffee cup as AI in it.
Yes, my fork. Although obstensibly ridiculous, as all AI projects are approaching designs with the goal of running it on a watch can push towards some good, clean design decisions. I think you got a good insight here, Damien, which is you're pushing on Conway's law that if we organize the project into logical units, those are the those become
the natural seams. So you start thinking about what are the areas of resonance, like what's likely to change, keep that separate, and whether you compile it all into one big assembly or not doesn't matter. Right, The deployment is separate from the construction. So Damian, thank you so much for your comment, and a copy of musico By. It's
on its way to you. And if you'd like a copy of musico By, I write a comment on the website at dot at Rocks, dot Commra on the Facebook, so we publish every show there, and if you comment there at everyady on the show, we'll send you a copy of music Oe.
And you can follow us on the other social media's. We've been on ex Twitter forever. We're also on mastadon and at Blue Sky, which is really coming along, and some aberration of at Carl Franklin and at Rich Campbell absolutely. Yeah. All right, So before we introduced Jeremy Miller, let's talk about nineteen thirty nine. Some significant events included the start of World War two.
Yeah, that's kind of a significant event.
Yeah. Germany invaded Poland on September first, leading Britain and France declare war on Germany. Additionally, this year saw the debut of iconic cultural works like The Wizard of Oz and the first NCAA basketball tournament. What do you got on near lest Richard?
You know, I've been doing I've been doing the future of energy since the Worldwide Energy Geek out what ten years ago, and that finally spun into folks asking me to do talks just on nuclear power, which and now I've done for the past year or so. And interesting, curiously, I started doing them before it got really exciting, because
it really has been around on to nuclear power. But one of the cornerstones of that entire story is starts in nineteen thirty nine when Autahon and lease Meitner published the paper on splitting a uranium atom for the first time. Wow, And interestingly, they calculated the yield of the energy of splitting that atom from Einstein's nineteen oh five paper equals mc squared and he was absolutely completely right, Like the
numbers worked perfectly. So thirty something years before this guy had figured out, well, if you really could convert matter into energy, this is how much you'd get. And that paper is sorted to the foundational piece like first time the intentionally split the ADAM was nineteen thirty nine and eighteen forty five they will deploy the first automic bomb.
I don't know if it was this paper or which one that after it was proven, they came to Einstein and said, professor, you were right, you were right. Isn't that a victory for you. He says, no, it's a victory for God.
Very that's very Einsteinian. Yeah, yeah, but yeah, he's it's amazing how quickly all of that happened. Yeah, you know. The good news is from that came this paper from the English, the mod Report, that said both we can use this to make energy and we can use this to make weapons, and whereupon they probably did both.
Yeah.
Yeah, nineteen thirty nine pivotal year and.
A pivotal episode of dot net rocks. Because our old friend Jeremy Miller is here. And you know, if if you're younger than us. You probably you might know who he is, but if you've been around for a few years like we have, you'll definitely know. So I'm going to read your bio anyway. Jeremy Jeremy Miller started his career as a real engineer that's in quotes, but wandered into software because that looked like more fun. Since then, Jeremy has worked in and led software development teams in
the computer manufacturing industry, finance, insurance, healthcare, and banking industries. Lately, Jeremy has been focused on leading software architecture and teams and helping mentor other software architects, and by lately I mean the last ten years right. Having had roles both as an in house software architect and software consultant, Jeremy has a great deal of insight into the challenges that
confront companies developing and maintaining enterprise systems over time. Jeremy is well known for his open source software tools, starting with structure Map and continuing to Martin and Wolverine and others. Jeremy is also a frequent author and technical speaker at software conferences and can be found at JEREMYD. Miller dot com. Welcome back, sir, thank you very much and very sorry.
Let me apologize for writing such a ridiculously long I hope for you.
Well, people need to know who you are, and uh, yeah, you're the guy. And Hibernate Mafia member is not in there, however, heard.
Oh if we could just kindly kindly let that one, that one go by.
A long time ago.
Man, that's right, nobody remembers.
Yeah, most of your audience, most of your audience is wondering, what is it Hybernate.
That's all right, we don't need to tell him.
How is the critter stack these days?
Yeah, so the critive sack. Somebody was making fun of that today. Martin and Wolverine moving along very well. So at this point, you know, the shameless plug park. At this point, I would say Martin is the most widely used to ben sourcing tool dotnet. I think it's by far and away the most robust. I think we're this. We had such a huge year last year in terms of future development. I think I'm ready at the point to say I think we stand up against any events
sourcing infrastructure across any ecosystem. Nice good Wolverine completes Wolverine and some other littler things complete the the the whole critter stack, and that is that's a purposeful theme. Moving really fast on that, and like one of the specifics we'll talk about is how Wolverine has some special sauce for doing vertical slice architecture and almost to take the well, eventually you're gonna let you, you're gonna make me, let me take a tangent on your comment from Damian earlier.
It's also developing a lot of special sauce for doing modular monoliths, and we might wanna, might want to talk about why the modular monolith idea is absolutely not a silver bullet and there's a lot more challenges than I think people are recognizing right now.
Yeah, dude, if there was an easy way to do it, we'd be doing it. Everything is hard.
Yeah, it was easy.
You could buy it at seven to eleven. Everything is definitely hard. You know, we've kept circling back on this idea. I mean, of course twenty something years have done at Rocks. We've gone through it all. Man, Like, remember when SOA was a good idea and yeah, then we talked about the various globs of goo and now you call them monoliths and then you know this modularization or peeling pieces off like it's it's a cycle, right, you know, we're all trying to build better software.
SOA was an eye opener for me, not in the implementation that was suggested at the time, because I thought that was way over architected, but just the idea of having islands. I thought that was a good idea, and it was one that hadn't occurred to me up to then.
I think you read it to it more so. I was a Dell Computers at the time when when Dell
still manufactured their own stuff. So I'm trying to apply that to at the time manufacturing it when you have shipping systems and inventory systems and a million and one little one off things where they may need to want to talk to each other, where you don't want to duplicate as much data, you know, SOA was it was attractive at least in theory, right I don't I don't think anybody wants to reuse any of the mechanisms we use back then though.
Now, yeah, that's exactly what I'm saying.
Tooling is always a problem with this idea that SO was catching. It was basically at the forefront of the fact that we were about to blow the client up, right, that that you were going to have phones, were going to be real clients. There was going to be multiple devices and multiple platforms, you know, coming out of the wind Tell hegemony where you were building on the same machine that everybody was working from. Or we didn't ever think about it all that, which was a weird time.
It is always said, hey, this back end code you'll work for everything. You'll only have to write that once and now you'll be You just got to set a services that you can decide what client you want to use.
Yes, that also went also went a lot easier when we gave up on the full XML soap.
Thing and oh lord save from eximum.
Yeah, we're old enough. We lived through.
The wisdole, the wisdole nightmare.
Yeah.
Hell uh are systems that did three or four levels of XML transformation to the point where you had no traceability between up to downstream.
Right, we should never have needed biz talk.
Yeah, I mean the origins of bis talk before the soap layer were you know, pre Internet intercommunications, Like they were doing serious transformation of data for connecting between companies. Right, the fact that we standardize the network and then it starts standardizing protocols. You're right, we should have been able to move away from it biz talk. I think just tried to stay relevant. Yeah, Plus we kept screwing up.
These interplay protocols were bad, right, and they were always bad like CORBA was bad.
Is the last we will go down this rabbit hole. The last video I recorded, we talked about DCOM, a DCOM war story.
So oh boy, and you know the D stands for dumb.
Welcome to three old guys talking about technology that doesn't exist anymore.
But to the to your point, it's better now, right, Like we have learned, we have better platforms, we have more standardization. We we understand what a cloud proxy is for and why it makes our lives so much better. Like things are better.
I'll go farther the done it, I mean, we're all done at guys. Here the donet ecosystem, I think it's just generation vastly better after the dynat core wave of things. Some of the low level abstractions that they put in place I host, the I configuration, eyewagger, those standard interfaces, the I host builder, so much of that has.
I'm coupling it from Windows entirely. That process, that rething just made it a better profit platform.
Yes, I'm I'm doing this on a Mac. I haven't coded on Windows in years except for Pararelel. Yeah. Love the new World Order.
Now with dot net nine.
Yeah, well, and in the cloud, you're crazy not to run it on Linux. Run dot nen olynux. It's a twenty five percent discount if you do.
It and add dot Net nine into the mix and using what eighty percent less memory or something crazy like that. Dot Net nine uses so much less memory.
So I'm not I'm not really running apps in production to know that, but I can say every time we get a new dot net version, my build times go down. Yeah, yeah, cannot complain.
And you and run times are faster like they really, I don't know how they can keep this up. Is there a law? Is there a law of this? At some point it's only one bit being flipped, and that's just not enough.
There it is Campbell's law right there. Yeah, you heard it here. First, we will continue optimizing until there's only one bit.
Yeah, down to a bit. Wait, we were going to talk about something today, I'm sure what we were.
We were vertical architecture with some thing you expressed an interest in.
Well, it's taking out the vertical slice architecture. But so this might be a sequel to a sequel or continuation in the last time time I got together with you got it? M h. So the phrase vertical slice architecture, it's popularized by by Jimmy Boguard in the dot net space. It's you know, it's very very tightly associated with mediator. Of course, Wolverine supports it, supports it quite differently potentially, but I guess maybe stop and you know, to explain
what it is. I always got to stop and contrast it to what's coming before or what's really the state of the art, at least a few years ago. I'm sure you guys have plenty of shows with folks coming on to talk about clean architecture, onion architecture, extagonal ports and adapters, done it right. I've been there, done now.
So they're very well meaning attempts to try to, you know, establish a kind of a standard for a team get better results of we want to disentangle business logic from infrastructure. We'd like to make things testable. And then folks started to throughout all of these enterprise architecture templates, these prescriptive you know, look at my repository and I'll tell you the emptying projects. You have to divide things into the rules of what things are called, how they're divided. You
know where this goes. So I think we took a couple of wrong terms. We you know, first thing we did is these these temples tend to focus too much on, you know, the nouns of the system. I have an invoice controller that talks to an invoice service that must talk to an invoice repository, and they've all got to be an emptying different.
Projects, right, an email sender.
Yeah, and you know every system, every enterprise system, grows until there's messaging service right right. Yeah, I've done lots of those. But you know, it's made us kind of overemphasized, maybe throwing in a lot of abstractions. You know, we we maybe took a little too seriously the idea that it has to be possible to swap out your infrastructure at a moment's notice, which you know nobody really does
are very rarely right. So what happens in bigger enterprise systems is you get these huge horizontal layers where every use case has to bounce through all of these separate layers, and it becomes very difficult to reason about a single use case. It's all scattered around, right. You can't really update anything anyway, even though you have these abstractions, because it's a full project to replace the database or upgrade
a technology. It's just too bit So. The kind of Reacto logical reaction to that is the idea of a vertical slice architecture we are going to take. We're going to primarily organize code, and here I'm just talking about how we situate code. I'm not even really talking about changing the basic constructions or anything like that, but we're going to try to lean towards organizing code around use
cases or especially works well with cqurs. I'm going to organize code around the command and everything it takes to handle that command or ACQUERI and everything that they square it. The general idea is I'm going to take things that are closely related and I'm going to put them together, and things that are not related, I'm going to spread them out.
Right, So the vertical slice is starts when somebody clicks a button, let's say on the website and ends when there's a result, an end result, whether that goes through a queue or through databases and all these other services, all those things happen in one place that isn't shared with the other slices.
So I won't go so I will go all the way to that extreme. I mean, I would say it's perfectly valid to share some helper code. But yeah, so I really think of it as like a single web request. You're issuing a create invoice or approve invoice command to an HP endpoint. So everything that it takes to fully apply that, you know, whatever data you need to fetch, reading the HP validation business rules, it might have to happen in finally, persistence, if you were using you know,
Woolring for example. Our idiom is to try to push you to really do that in one code file.
So, I mean, are you talking about everything through all of those layers just being a single apply.
Well, you're you're separating the UI though, right.
Yeah, yeah, if it's small enough.
Yeah.
Yeah. I'm a I'm a back end guy. Oka, yeah, Okay, nobody would let me do front end work unless you you're desperate.
Yeah, I don't think you'd want to put that in your UI. Yeah.
No, no, no, no no, I mean that there's a there's a fallow up conversation. Get somebody on to talk about composite UI someday. But that's okay. So if it's if the use case is small enough, I mean, if it gets big, and you know it's probably with all those prescriptive templates, they blow up. Is sometimes a particular use case may be too big, and then you start splitting things up helpers, maybe you draw out split off
message handlers. But what we're doing with vertical slice is we're saying, you know, we're not so worried about necessarily swapping out infrastructure. But I'll come back to that. What you want, though, is you want to make it as easy as possible to reason about what is happening in my system from this input to the outputs it makes because the business logic changes all the time. Yeah, and that's where your bug fixes are going to go.
So you're saying, if you have everything in one file, you don't have to step through the debugger and find out which modules are being touched in which where they're coming. And then now you've got this mental list of all these places where you have to make changes. It's all in one file.
In the ideal and the ideal you know some things are going to be too big for that yet out. But yeah, now to your point, I mean to go into apostasy here. You know, if you're doing it to Wolverine style, we're going to push you to ditch repository layers. Well, at least as a go to default move. There's always exceptions to directly utilize. If you're using a core use the dB context. If you're using Martin Martin, you're going to use I Document Store, Die document session directly with
a huge caveat here. You know, in our case, we want it still to be in one file, but we'll take other steps to isolate the business logic code away from infrastructure so you can and kind of I'll come back to that, but to be able to go right down to the metal so you can use every last bit of power in your data persistence tooling. You know you need to fiddle with lazy versus eager fetching to be faster. You need to batch up quaring to be faster.
Would you still want to use a CRUD interface. I mean, that's the essence of what a repository is. Isn't it so that you could swap out whatever you know, database back end for testing memory repository for example.
Okay, so this is the part where people are going to give you angry comments later, right, No, please bring it on a little bit controversy. So we've got two issues here. You know, on one hand, what are we going to do to be able to swap out infrastructure? Right?
Mm hmm.
We're going to put a pin in that and come back to it.
Okay.
Second point is how do I make code testable? Yeah, so, especially with the wolverine style, we're leaning really heavily into an idea from Jim Shore called the A frame architecture. So in the show notes all I'll sen Joe Link there's a paper called Testability without Mocks. I recommend to everybody who works with me sooner or later the A frame idea like that. Now, if you're talking about, say we're building a wolf wearine handler, either an h should
be handler or a message handler. That is mean. Let's say it's a proven invoice, right, so you probably need to go get the current state of the invoice because you may need to look at it. Is it already approved, is everything done? Has you know everybody signed off? Whatever it takes, and then decide, decide your business logic, decide what do I knew? Next do I decide to approve it and go on and maybe send out other fall
up messages or not, and then finally persist it. So coming to this idea of an A frame, I'm not gonna worry about interfaces and mock objects or stubs or fakes or anything like that. We're going to divide things up into like kind of a controller on top, the a guy at top. He is going to reach into data persistence. He's going to grab the invoice data for you, push it into the business logic. Business logic. In the case of Wolverine, we're pushing really hard. We want it to be a pure function.
Now you keep mentioning Wolverine, but what if people don't use Wolverine and aren't really familiar with it. How can you give us an example that doesn't use Wolverine.
Actually, it's just extracting methods. So whether this was mediator or whatever, it's going to be, just say say you have a mediator handler and in service bus handler, mass transit handler, or just just an MVC controller endpoint. What you're really going to do is just build off some some helper methods and that's it. So one method is the controller, NVC controller is going to talk to E
of Core maybe and pull out the invoice information for you, ok. Right, and then it's going to call into a method that is your actual business logic. Who say, here's the command somebody wants to prove this invoice, and here is the current state of the invoice. And out of that pure function,
you tell me what to do next. You're going to return some kind of result that is, here's an event sourcing It could be here's an event I want you to append invoice approved or approval rejected, whatever it's going to be, or maybe something that reflects what to do next. Now our business business function here I keep saying pure function. You know we're gonna we're gonna dive into functional programming world a little bit. People are gonna make fun of me for this.
Now, nobody's making fun of you, dude, nobody.
No, people will on Blue Sky later.
So nobody.
We want to isolate that business logic or it's not depending on services, there's no interfaces to mock it's just if you have this state in this command, what do you do next? You get you get business logic in place where it's really easy to unit test, no mock set up, no crazy stuff, no in memory database, I don't care. And in the last step, you know, the A frame the controller is like I'm getting stuff for you.
I'm pushing into business logic and I'm taking what you decide to do next, and then I'm persisting it back to ef core maybe or Martin or whatever it is, and I'm sending out extra messages. So the A frame architecture, it is really a coding approach, but it's a way to isolate your business logic without having to throw in a lot of abstractions, a lot of indirections and throwing out, you know, five different projects like you would in onion architecture.
Right, it simplifies because that that is the fundamental problem of all these architectures is that they complicate things and they add all these layers of abstraction for the purpose of what for you know, for for making it flexible. But then something is ultimately flexible, it's ultimately difficult to.
Use it is now back to rewind to the point and you're you. I think you were correctly challenged. Well, what if I want to swap out my database? Yeah, yeah, which you're unlikely to do, but you could, so.
I always finally, swap out the database defense a weak defense. It's like, you're probably not going to do that.
You can't. You can't because if you have a big enough project and it's a flat layer, you can't because that's going to be an entire project to do a full regression testing cycle, and most people can't do it. Your business partners will never let you do.
That, all right, But here's a I can give you an example where you would use a repository pattern basically a cred interface, right is use you could use the same interface on a client to create a repository that calls makes all your API calls, and you could use the same interface on that same client to do something against the client side database that I can't even remember the name of it now because I'm stupid, But I dB something dB all right.
Well just local storage?
Sure, yeah, look not local storage, but there's another there's another database that's built in a new browser. You can do that, right and on the back end, if you wanted to run things against repository that just uses memory collections to test all your stuff. But I think that is where you brought up another another thing that you can test without mocking and test without memory databases and things.
Yes, so I want to test, be able to test. I would really want to be able to test the business logic without without having to do a bunch of mock setups. You know, if you are as old as us, and I don't think you have to be anywhere near as old as US, You've dealt with code bases where the unit tests were unusually hard to work with because there was too much reliance on mocking libraries or fakes,
and those tests become very hard to reason about. They become very brittle because you'reation is too tightly coupled to the luck the system so indexed dB.
That's what I was trying to remember.
Sorry, gotcha, gotcha. I've read about it, never used it. So a couple of things. The I think your example of using a repository, I think that's perfectly valid as far as swapping out the technology. So the single I think the single best thing you can do to make your technology swappable is to invest very heavily in having
a very effective test automation infrastructure. That's the one thing that's going to give you enough feedback to do this, because you can't just swap out interfaces if you can't test your app very fast. Right, that's one thing we keep touching on modular monolith a little bit. And I think all this is related. I don't think if you have a big system, it's impossible. It's effectively impossible to swap out infrastructure in most project planning. But if you have a way where you could do it bit by
module by module, maybe you could pull that off. Or if you keep upgrade from whatever SQL server to sql server to postgraphs for the cheap or hosting, or move to a different no SQL database or get off Mango dB or whatever it is, maybe you can do it one module at a time. Right, a couple other things, you know, diving into things like performance and whatnot. These database engines, they do not work the same way at all. Ef core might be a perfectly good abstraction over relational databases,
which are much more similar than not. I mean, maybe you can go from SQL server to postcraph, but going from a relational database to a no SQL database. That's a very different ballgame. The same abstractions are not going to work, even the link the link providers, there are a lot of extensions. You know, people use these repository abstractions where they let iqueriable link leak out that that's probably a terrible idea.
Yeah, they no good, that's a terrible idea. And and by the way, it doesn't work.
It doesn't work.
Inquible requires code, doesn't it. So it does, but it's not data.
To make it fast, your equeriable is going to need a lot of tool specific usage in a lot of cases.
Yeah, you can't just pass that from a to a client from an API controller. Yeah, so ask me how I know.
Everybody's done that. One I try to the testability point you brought up. He's like, of course people get excited about the in memory provider. It's going to behave very differently than your real database. It will give you false positive.
So another thing I'm going to say is when you're picking technologies, you very purposely try to pick technologies that have a very good testability story, right, that play very nicely inside of automated testing, which is to put my money where my mouth is on that one, taking Martin as either document store or it store. Martin has built in functionality to set up databases on the fly if you're in development or testing time, and it has the ability to wipe your database out in one command line.
The point being here is it's just it's actually much friendlier inside of an integrated test harness then we would have been used to twenty years ago, where that was almost impossible.
Yeah. Hey, getting back to my love for repositories. One of the things that I do is I have a an EF repository that's generic, and then I have a generic Dapper repository. I have a GENERICADO dot net by itself repository. And that's good because you know, if you start out with a customer and they like EF and then there's something, something happens, something whatever, and they're like, no, we don't like this anymore, we want to move to
ado dot net. Well, then I'll try Dapper. Right. So I'm not really changing the database per se, I'm changing the code that accesses the database, and so that's one of the reasons why. But I want to get your reaction to this after the break, which we're doing right now. We'll be right back dot net rocks. Hold on, We'll be right back. Did you know there's a dot net on aws community. Follow the social media blogs, YouTube influencers
and open source projects and add your own voice. Get plugged into the dot net on aws community at aws dot Amazon dot com, slash dot net. It's dot net rocks. I'm Carl Franklin. That's my friend Richard Campbell hey, and our friend Jeremy Miller. And want your reaction to uh to my love of repositories again and then we'll get off this. I swear to God.
No to today's point, what if you want to switch quickly between dapper rideo, dot net or Core, or you would to go to old school and bring in hibernade back because that does still work.
I have no idea what you're talking about.
So if you're doing that, I think you're in a world of I think that might apply well to more of a creud centric world where I'm editing in order at a time I'm adding a you know, an invoice at the time. You know, I hate the phrase pick the right tool for the job, but pick the right tool for the job. Most of what I'm talking about I do deal with larger systems with a lot more workflow, a lot more complexity than a CREUD system. So what you're talking about, I think that's fine for something that's
mostly about editing data. But right off the bat, so you know Richard's an old database guy.
You mean old.
Is not.
So no older than you?
There are these by two weeks you can write really bad database you know, database sequel queries. My experience can't speak for everybody else. My experience, by far away, the worst cause of very poor performance with the database is being chatty, making way too many calls back and forth to the database, even to the point where you know, in these layering things where you might be calling for the same data over and over and over again and
you don't even know it because you can't see it. So, taking that as an example, say you have this is pretty common. You have a web request and then the course of handling it, you need to look up three or four different entities at a time. Sure, right, and if you take some kind of repository abstraction approach, you're you don't have to do this, but you probably fall down that path of having a totally separate repository for
each and right common. That's almost forcing you to do a very naive, least common common denominator approach of I'm going to go roll a one and load the second and load the third. You may be doing it in plus one.
Yeah, absolutely, Yeah, there's there's a lot of there's a lot of queries that just don't that doesn't fit. Yeah. I mean that that's why we have STAR procedures, isn't it. You know, we have a procedure that gets Okay, he's just wincing. Now, he's wincing. He's he's got his fingers over his eyes.
It's a polighter way to say that, which is there is an opportunity for DBAs to provide optimizations to you.
Yes, yes, yes, of course, I mean that this is one of the reasons why STAR procedures exist, right besides the exist you know, came into being, shall I say, because of the abstraction one, but also because we could do complex queries in return complex result sets.
So technically yes, but to our point about trying to prefer tools that give you easier and easier time in integration testing. Sure, if you're depending on stored procedures and for procedures with logic, you have made your code as hard to test as I possibly can.
I totally agree, and I have since sworn them off. Jeremy, I have I swear to God.
Now and start procedure should be the exception, like, we can't seem to make this go any faster. What do we got to do? And the DBA can help.
Yes, But the point, the point I was getting at is but I also say, you're using a no SQL database yep. Or you know, for me, Mark, most of my clients are using events store. One where using an event store tool, so you're dealing with projections and all kinds of things.
Yeah.
The point is your underlying tool has probably has some kind of special sauce power to do batch Quarry Martin, for example, will let you line up I want to run this link, quarry this link, query, load this entity, load that entity, or and go do it in one batch. But I'll also say I want to load this entity, but I want you to find its related thing here and it's third related thing and do it in one network round trip. That is a massive cost savings in
terms of performance. Sure, so being able to go right to the metal, you're not really going that close but using all the power that you're underlying infrastructure has and then putting it in one vertical slice where you can actually reason about what are the database queries I'm actually making from this system input to get my data out. That's going to be the best possible chance of getting something that's very performant.
Can we talk about the second vertical slice you're going to take like you talk about the vertical slice approach to get started. Essentially, let's get something running a particular feature set and and you know, one time, even an agile we want to call that a spike, like we're
gonna test this thing. My concern with this approach is always then more teams start working on their slices and we're duplicating work, or we're coming with different styles, or you know, they don't ever play with each other very well.
So a lot that's going to boil down to communication. But that also gets into a conversation I did want to I did want to have with you guys. You know, the folks that really like to have those prescriptive architectures. Some of it is about standardization and take away. People need to be creative or think kind of kind of straight jacket in into doing a one one wayfect.
Right that there is one right way for this app.
Yeah, so I'm gonna give you a sports fan, right, and if you follow your team long enough, you're gonna hear the phrase a lot of this player is a high I four player or this other player could raise the ceiling of the team. And all is when we talk about a player's floor ceiling, you kind of say we expect to be at least this good. That's the floor. When you say raising the ceiling, we could potentially be even this much better. Folks that really care about standardization
across teams, they're trying to raise the floor. They're trying to say I want a minimum quality by saying everybody just do it the exact same way. Theoretically you can move around. People don't have to think so much. They can just go. There's obvious value, there's obvious attraction. The only problem is that it doesn't work very well. Righthew, you get these these one size fits all templates, what happens is you get use cases that are vastly more
complicated than your clean architecture approach. Shows if you make people stop thinking like I'm straight jacket into this approach, they stop thinking and they start writing just those massive, bloated NBC controllers which to mediator pulling it out, and now you have bloaded mediator handlers. People forget to do things like I'm just going to extract a helper method
out and compose my method. Or you on the other side of things, your prescriptive template may be more complicated than it should be, and you get a lot of straight pastors. I've seen that as well.
So now this is always a challenge. If it's simple enough to use, it's not sophisticated enough to do what you need to do. And if it's sophisticated enough to use, it's too complicated to understand.
So you know, the duplication, I mean, that's a real problem. That's absolutely a legitimate, legimate concern. What I would say is communication between teams. Hopefully your team is still working in a you know, it's kind of a DIT style bounded context where they have an isolated PURBUW to some degree, and then there's not much natural duplication except in infrastructure,
you know, being able to rotate around teams. You know, this is this is orthogonal to architectural style in places where you do see duplication in code, you start to do some refactorings to gather up the duplication, just like we've always done.
In some ways, I can almost see you describing this as a good problem. You've gotten to a place where you've built enough that they can see the duplication, and now you can put an initiative to try and consolidate that and make things a bit more Yes, I would also think the first slice you pick in a green field app is going to set the tone, so pick carefully.
Maybe maybe yeah, But taking this, you know, down the people side of things, you know, rather than saying, here's this very limited straight jacket rule of you know, we downloaded somebody's GitHub repository that lays out a clean architecture or something or other. Right, having a constant learning environment where your people are empowered to learn an experiment a little bit, as long as you can trust that they'll communicate with each other, so that that's what I would
describe as raising the ceiling of your your shop. You know, you have a chance to do things much better.
I mean, I think it's reasonable set minimums, but don't don't require where people stay at the minimums like I think I have to enough smart enough to go when to know when they're going below it, but not be concerned when they go above it, because that's ultimately a.
Good thing, definitely that. And then all of us learn. If you're ever a technical lead, so here later you're going to learn a hard rough lesson that. The more specific direction you give to somebody working with you, the worse the results are coming back. Sure, because if you turn off the brain, you make them just.
You know, I've seen Carl do this with music, where he pointed the bass player and said, just be awesome.
Just be awesome. That's a true story, the true story. He says, what do you want me to play here?
He was awesome?
Said I said, just be awesome, and he.
Was, yeah, that's awesome.
But you know, I can think of some devs where he's that's all you need to tell him is, hey, just be awesome.
Just be awesome. Don't write bugs.
Well, yeah, and then then let me let me rain some of that in of you know. Also, folks, don't don't get too creative, don't get too crazy. No matter what tool you use, use it in the idiomatic way. Don't write your own special frameworks, that kind of thing.
I remember the Onion article Apple employee fired for thinking too different.
The way I always pitched it to my devs was, I want you to be able to take a vacation, so somebody else needs to be able to read this code. Yeah, that's right. Motivation just you know, give yourself, be able to give yourself a break.
So running right back to our vertical slice architecture idea, we are trying very hard, you know, and again I'm so plugging it. The approach we're taking with Wolverine, especially, shrink your code down, take out so much code ceremony that you can hopefully very easily reason about your system
follow one place. There's less code period, there's less hoops to jump through, and even a strange person could come in as as they are a developer, they can see, yeah, right, understand how it's working top to bottom.
I get this. Yeah, and so maybe you can actually take two weeks off and the world doesn't hold still or burn to the ground.
I'll let you know if I ever do.
I always thought it was a good milestone, right, was like, are we functioning enough of the team that somebody can go away for a while, and not that we don't burn to the ground, or even that we can hold everything still, but that we still made progress without them. Yeah, they came back to not an inbox that killed them, that punished them for taking their time off.
I I think I've told this story before. The first project where I was a technical lead on a project that was actually important, all of my managers, two or three times a day would ask me, well, what are we going to do if you get hit by a bus?
Right?
That's the very real thing.
And I heard that so often that I started seriously pondering my own mortality.
Yeah, and it got it. You want to hit the bus so bad?
Isn't that one of Steve Smith's anti padd or whenever?
The bus being hit by bus is definitely an anti pattern.
No, no, no, but you know the one bus, the one bus, low bus factor.
Yeah, that's it, Yeah, low bus factor. But that's why I went with the vacation scenario, because it seems less you know, mortally threatened.
It's less morbid. It's a very Canadian approach to that metaphor.
I was just gonna say, I'm an American. I don't know what a two week vacation would be. Yeah, I mean I've had one once.
Maybe right, better software through politeness, just.
Trying to keep people healthy and happy. You know, the death We took over a team that had been death marching for like six months and they and the boss is like, what do you suggest this is? I'm thinking a three week I think a three day weekend first, like, just send everybody home for three days, take a breath, will We'll reorganize next week. Absolutely, you know, you can't just keep beating people. We're not making progress anymore and
everyone's miserable. Got to get up and take a walk once in a while.
I really say, I haven't been on a death march in a few years, but I certainly did my share of them back in the Waterfall doos.
Yeah. Well, and it's one of those things where everybody's built their parts and you've tested in various bits and now you're trying to really get to a deployment and does it actually scale away it's supposed to behave and are the people happy with it? And then it's patch patge patch, like what are we missing trying to get to that magic V one that somebody promised on an arbitrary date. They didn't understand.
Yeah, yeah, or the day as a tech lead, the tester asked me, what about the reports from the requirements? And I don't know what you're talking about. And there was a second requirements document I had never been shown until then. Yeah, and we were already in the official testing phase.
Yeah, surprise. Yeah, I should have known about this a year ago.
Waterfall for the win.
Abbreviated WTF waterfall? What's in your inbox? Jeremy, what are you going to do next?
So probably won't show up in a conference until till later next year. I did so many late last year
that I'm didn't get get submissions off. But the big thing I'm working on right now in my company, jazzper Effects Software, working on a tool called critter Watch that is a commercial management console monitoring tools specifically for the entire Critter stack, So everything you would need to not just watch what's going on your system, but also be able to help heal the system, deal with did letter
Q messages. Eventsourcing creates all kinds of extra stuff, problems of being able to kick off projection, rebuilds, rewind subscriptions, turn things on, change how change what servers things are running on? Maybe to deal with privacy concerns, be able to retroactively say we're going to do something called crypto shredding. We're just going to throw away the key so we can't read this client data anyway. You know, all kinds
of good stuff like that. So trying to make the jump from you know, we're a services company around open source tooling right now, but we want to make the jump to also having that paid commercial add on that.
That's very cool, cool. Well, hope you come back and talk to us when that's in play, you know, or if you have any other things that are new, just feel free to reach out and come back on the show.
All right, we'll certainly do that, guys.
It's always a pleasure.
Thanks thanks for having me.
That's been a pleasure for us too, And we'll talk to you next time on dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of
course in the cloud online at pwop dot com. Visit our website at d O T N E t R O c K S dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now go write some code. See you next time.
You got javans
And no