Speaker 1: 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.
Speaker 2: And then NBC London.
Speaker 1: I saw the posts you did from Mexico with our
friends Paul and Stephanie.
Speaker 2: Yep, they came. They came down for a week with us,
and then I was at NBC London and then Sweet
Dug in Stockholm.
Speaker 1: Very cool.
Speaker 2: So you saw Fritz there, I believe I did. The
Fritzy was there, The Hunter was there, the Handsoman.
Speaker 1: Wow, that's cool.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Oh my goodness, it has been a while.
Speaker 1: 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?
Speaker 2: Yeah?
Speaker 1: You should, all right, I should go ahead, So there
you go. It's just a little bit of it.
Speaker 2: Awesome.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: To have a cy my coffee cup as AI in it.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Yeah, that's kind of a significant event.
Speaker 1: 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?
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Yeah.
Speaker 2: Yeah, nineteen thirty nine pivotal year and.
Speaker 1: 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.
Speaker 3: Let me apologize for writing such a ridiculously long I
hope for you.
Speaker 1: 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.
Speaker 3: Oh if we could just kindly kindly let that one,
that one go by.
Speaker 2: A long time ago.
Speaker 1: Man, that's right, nobody remembers.
Speaker 3: Yeah, most of your audience, most of your audience is wondering,
what is it Hybernate.
Speaker 1: That's all right, we don't need to tell him.
Speaker 2: How is the critter stack these days?
Speaker 3: 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.
Speaker 2: Yeah, dude, if there was an easy way to do it,
we'd be doing it. Everything is hard.
Speaker 3: Yeah, it was easy.
Speaker 2: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: Now, yeah, that's exactly what I'm saying.
Speaker 2: 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.
Speaker 3: Yes, that also went also went a lot easier when
we gave up on the full XML soap.
Speaker 2: Thing and oh lord save from eximum.
Speaker 3: Yeah, we're old enough. We lived through.
Speaker 2: The wisdole, the wisdole nightmare.
Speaker 1: Yeah.
Speaker 3: 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.
Speaker 1: Right, we should never have needed biz talk.
Speaker 2: 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.
Speaker 3: Is the last we will go down this rabbit hole.
The last video I recorded, we talked about DCOM, a
DCOM war story.
Speaker 2: So oh boy, and you know the D stands for dumb.
Speaker 1: Welcome to three old guys talking about technology that doesn't
exist anymore.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: I'm coupling it from Windows entirely. That process, that rething
just made it a better profit platform.
Speaker 3: 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.
Speaker 1: Now with dot net nine.
Speaker 2: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 1: There it is Campbell's law right there. Yeah, you heard
it here. First, we will continue optimizing until there's only
one bit.
Speaker 2: Yeah, down to a bit. Wait, we were going to
talk about something today, I'm sure what we were.
Speaker 1: We were vertical architecture with some thing you expressed an
interest in.
Speaker 3: 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.
Speaker 1: Projects, right, an email sender.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: So, I mean, are you talking about everything through all
of those layers just being a single apply.
Speaker 1: Well, you're you're separating the UI though, right.
Speaker 3: Yeah, yeah, if it's small enough.
Speaker 1: Yeah.
Speaker 3: 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.
Speaker 1: Yeah, I don't think you'd want to put that in
your UI. Yeah.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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?
Speaker 1: Mm hmm.
Speaker 3: We're going to put a pin in that and come
back to it.
Speaker 1: Okay.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: Now, nobody's making fun of you, dude, nobody.
Speaker 3: No, people will on Blue Sky later.
Speaker 1: So nobody.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: I always finally, swap out the database defense a weak defense.
It's like, you're probably not going to do that.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: Well just local storage?
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: That's what I was trying to remember.
Speaker 3: 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.
Speaker 1: Yeah, they no good, that's a terrible idea. And and
by the way, it doesn't work.
Speaker 3: It doesn't work.
Speaker 1: Inquible requires code, doesn't it. So it does, but it's
not data.
Speaker 3: To make it fast, your equeriable is going to need
a lot of tool specific usage in a lot of cases.
Speaker 1: Yeah, you can't just pass that from a to a
client from an API controller. Yeah, so ask me how
I know.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: I have no idea what you're talking about.
Speaker 3: 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.
Speaker 1: You mean old.
Speaker 3: Is not.
Speaker 2: So no older than you?
Speaker 3: 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.
Speaker 1: 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.
Speaker 2: It's a polighter way to say that, which is there
is an opportunity for DBAs to provide optimizations to you.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: I totally agree, and I have since sworn them off. Jeremy,
I have I swear to God.
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: Yeah.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: Right that there is one right way for this app.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: You know, I've seen Carl do this with music, where
he pointed the bass player and said, just be awesome.
Speaker 1: Just be awesome. That's a true story, the true story.
He says, what do you want me to play here?
Speaker 2: He was awesome?
Speaker 1: Said I said, just be awesome, and he.
Speaker 3: Was, yeah, that's awesome.
Speaker 2: 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.
Speaker 1: Just be awesome. Don't write bugs.
Speaker 3: 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.
Speaker 1: I remember the Onion article Apple employee fired for thinking
too different.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: I'll let you know if I ever do.
Speaker 2: 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.
Speaker 3: 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?
Speaker 2: Right?
Speaker 1: That's the very real thing.
Speaker 3: And I heard that so often that I started seriously
pondering my own mortality.
Speaker 2: Yeah, and it got it. You want to hit the
bus so bad?
Speaker 1: Isn't that one of Steve Smith's anti padd or whenever?
Speaker 2: The bus being hit by bus is definitely an anti pattern.
Speaker 3: No, no, no, but you know the one bus, the
one bus, low bus factor.
Speaker 2: 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.
Speaker 1: It's less morbid. It's a very Canadian approach to that metaphor.
Speaker 3: 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.
Speaker 1: Maybe right, better software through politeness, just.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: Yeah, surprise. Yeah, I should have known about this a
year ago.
Speaker 3: Waterfall for the win.
Speaker 1: Abbreviated WTF waterfall? What's in your inbox? Jeremy, what are
you going to do next?
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: All right, we'll certainly do that, guys.
Speaker 1: It's always a pleasure.
Speaker 3: Thanks thanks for having me.
Speaker 1: 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.
Speaker 3: You got javans
Speaker 2: And no