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, welcome back to dot net rocks. I'm
Carl Franklin and I'm Richard Campbell. We are here for
your dot net pleasure.
Speaker 2: And any other pleasures you want. But you know, don't
get crazy.
Speaker 1: No, I'm gonna limit it to dot net Okay, maybe
geek up pleasure, maybe a little science.
Speaker 2: Yeah, I'm writing my indie year geek outs. Man, it's
a pile of work, but I am working on them.
Speaker 1: That's great. I can't wait to can't wait to hear them.
Speaker 2: Yeah.
Speaker 1: All right, Well let's get started with a little thing
we call better no a framework.
Speaker 2: Awesome. All right.
Speaker 1: So I went looking to see what's trending as far
as c sharp repositories on GitHub, and one that has
recently got a lot of activity or a lot of
coolness is Tom Hurst's t unit a modern, fast, and
flexible dot net testing framework. Now I have never used it.
I don't know anything about it except what it says
in the repo, which is that it's modern and fast.
T unit leverages source generators to locate and register your
test as opposed to reflection. Nice you'll have a slight
bump and build time, but a speedier runtime. T unit
also builds upon the newer Microsoft Testing platform that's Microsoft
Dot Testing dot Platform. Whereas most other frameworks you'll have
to you'll use, we'll use vs tests. The new platform
is reconstructed from the ground up to address pain points,
be more extensible, and be faster.
Speaker 2: So this is just a play on x unit, but
x unit depends on reflection, and here they're using analyzers.
Speaker 1: Yes, some sort.
Speaker 2: Of modernized cunts. It's sort of modernized. Yeah, that's good idea.
I like that.
Speaker 1: Yeah. So, like I said, it's trending and you might
want to check it out. That's when I got Richard,
who's talking to us today.
Speaker 2: Grady comment to off a show nineteen sixteen. So that's
the one we did with Rendell back in September. They
show I called how Simple is as Simple as Possible?
Speaker 3: Right.
Speaker 2: I mean, Rendell's a smart person, right like, he just
thinks about development really coherently and very typical of you know,
how do we do the right thing the right way?
And it kicked off a ton of comments, lots of
people reacting to the show, and Cash Bonfil said this,
he said, this is a really interesting show and if
it's writing discussions we're currently having at work. We're a
team of eight developers all together, so hardly the size
of Netflix. That it's okay, man, you don't need to
be this side of Netflix. Now, that's set of problems.
We're building a lot of micro services because we can.
It's all good, but it comes to the price. One
example is that we are making everything asynchronous, that is,
with service bus integrations in the form of topics and queues.
Again all good on paper, because every time we have
AC and communications between our very small services, we have
situations where things don't work out as it was supposed to.
Messages end up on dlques and someone or something has
to monitor and compensate. All of a sudden, we start
building endpoints and handles on how I allow messages to
be fixed and rerun. So we're spending our precious time
creating things to compensate for architectural and infrastructure things instead
of actually building business value. My point is that on
an architectural drawing, a simple straight line might end up
being insanely complex. Another funny thing, we started using dapper
that's DAPR for the exact reasons that Mendel mentions. Eventually
we left it again and it turned out to have
to be a horrible developer experience. Dapper is another great
example of being a good idea from an architectural point
of view, but implementing it it was a nightmare. I'm
pretty sure it will improve in the future, but the
moment it's too mature from a developer's point of view.
Thanks again for the great show. I always feel like
having a biscuit and a cup of tea when you
have rent a lot.
Speaker 1: Absolutely or some fish and chips and a stout more.
Speaker 2: Like, and it's stout and some mushy peas for sure.
Speaker 1: Yeah, you can keep this.
Speaker 2: You know, it's interesting that you've gone down that path
and you're seeing the struggles around all of it. And
again it's like, because you can thing problem now is
that d architecting would be an interesting challenge, although it
shouldn't be that tough. You've already done the hard work
separating concerns. Now you want to put some of them
back together. But great to hear the experiments going on
and the challenges there. And you're a pretty big team.
I mean eight people is enough that that ability is split.
The work up's pretty cool. So COJH, thank you so
much for your comment, and a coffee of music code
by is on its way to you. And if you'd
like a copy of musiccode buy, I write a comment
on the website at dot NetRocks dot com or on
the Facebook, so we publish every show there, and if
you comment there and I read it on the show,
we'll send you a copy of music cope or.
Speaker 1: If you feel like buying music to code but how
you can go to music tocode by dot net and
you can also follow us on ex Twitter. Of course
we've been there for years, but the cool kids are
hanging out. I'm mastaed on, I'm at Carl Franklin at
techeb dot social.
Speaker 2: And I'm rich Campbell at masadon dot social.
Speaker 1: Send us a two and uh, Richard. Before we get
started here, I realized that I didn't do my you know,
what happened in nineteen twenty three. This is show in
nineteen twenty three, and we've sort of vowed to do that.
Speaker 2: Oh wow, yeah, what happened in nineteen twenty three.
Speaker 1: Well, I'm going through the Wikipedia thing because my usual
page that we go to is down for some reason.
But let's just pick a few here. January fifth, Lithuani
begins the Clyppeeda revolt to annex the Clyipeda region. I
don't know.
Speaker 2: Oh no, this is pre World War two, right, so
you're talking about the fall that's sort of the fallout
of the end of the Ottoman Empire, and it's a
it's craziness for sure.
Speaker 1: March first, Eskom, the largest electricity producer in Africa, is
established in South Africa. March third, the first issue of
Time magazine is published.
Speaker 2: Wow, that's cool.
Speaker 1: March ninth, Vladimir Lenin suffers his third stroke, which renders
him bedridden and unable to speak. Consequently, he retires from
his position as chairman of the Soviet government. Let's see
British Prime Minister in May Bonar Law resigns due to
ill health. Okay, not all that oh, the Irish Civil
War ended May twenty fourth. Let's see what else I
can find here. July tenth, large hailstones killed twenty three
people in Rostov and the Soviet Union.
Speaker 2: Oh my wow, those are big hailstones that they're killing people.
Speaker 1: Yeah. July twentieth, Pancho Villa is assassinated a Hidalgo de
Palo Shiwawa. The Treaty of Lusine is signed, setting the
boundaries of modern Republic of Turkey in Switzerland.
Speaker 2: Right, I would argue the big thing in twenty three
is the beer hall push is that's the beginning of
the first coup attempt by Hitler and his go court
hearts that failed.
Speaker 1: Beer hall push, Beer hall pushed, Oh, pohar pusch. November eighth,
in Munich, Adolf Hitler leads the Nazis and an unsuccessful
attempt to overthrow the Bavarian government. Police and troops crushed
the attempt. The next day. Twenty people die as a
result of associated violence. And our friend Christian Vayer was
not born yet.
Speaker 2: No, but it did, you know? And one would argue
the lack of consequences for the party at that time
set them up for what would happen later.
Speaker 1: Yeah, I don't know why you brought that up. Is
there some sort of current event or something that you're
referring to.
Speaker 2: I'm not referring to anything, not referring to a thing.
I don't know what you're talking about.
Speaker 1: I don't know it's you're talking about either. Okay, all right,
let's bring in our guest. Vlad Honanoff is a software
architect with extensive industry experience, having held roles ranging from
webmaster to chief architect. He currently helps organizations make sense
of their business domains, untangled monoliths, and address complex architectural challenges.
In twenty twenty one, Vlad published Learning Domain Driven Design,
followed by his latest book, Balancing, Coupling and Software Design,
released earlier this month. As a public speaker, Vlad presents
at conferences worldwide on topics such as software architecture, demain
driven design, and distributed systems. And I believe this is
his first time on dot Netrock. So welcome, Flad.
Speaker 4: Thank you so much. It's such an honor been here.
Speaker 1: Oh you've heard of our show?
Speaker 4: Then, yeah, bit, I started listening to you in two
thousand and six, I believe, Wow, and then use Yeah,
spoiled experience of listening to other podcasts for me because
that's the quality I expected from the rest of them.
Speaker 1: Yeah, we get that a lot.
Speaker 2: We've always taken the engineering side of the show very seriously. Yeah,
the content we have more fun, but quality audio is important.
Speaker 1: Our content quality went way up when Richard joined the team,
that's for sure.
Speaker 2: That's a long time ago. Man, it's coming up on
twenty years, like in a few months.
Speaker 1: Yep, yep. And remember that serious lapse year that we
had before you came on, where we started doing comedy
and to two hour shows and what were we thinking.
Speaker 2: Two and a half? Yeah, it was a variety showed.
I remember talking about it. It's like there's a vent diagram here.
There's a vent diagram of folks who want a technical
interview and folks who want like music and geeky humor
and all those things, and the intersection is small, but
the two big other circles are big. Why don't we
just pull them up? Part that's right, So Mondays was born,
both shows got bigger.
Speaker 1: Okay, lad, enough about us. Let's talk about your experience
untangling monoliths and getting the balance of complexity right. What
are you talking about.
Speaker 4: Yeah, so actually the comment that Richard read that experience
sounded kind of similar to what I went through a
few years ago. We also had a system that was working,
that was producing business value, but it was a monolith.
It was a monolithic code base. So we said, okay,
let's make it better by breaking it down into micro
services or in other words, let's decouple things. Right, So
we introduced tons of services that we call the micro services,
of course, with asynchronous integration between them, and from that
point on, it was impossible to evolve that system. It
was impossible to change it because suddenly we had to
modify tons of those services or I don't want to
say microservices because they have nothing to do with micro services.
Speaker 2: Yeah, I don't know how. I mean, how do you
call it. It's only a micro service if you put
that in the comments, like, I don't know the difference.
It's just a service. Yeah.
Speaker 1: The thing is they're completely separated, right. But I guess
what we're talking about, and what we've been talking about
the complexity aspect of it is when you want to
implement a feature, you have to touch so many different
places to make sure that it is still going to
be robust.
Speaker 4: Yeah. Yeah, and again it started with that decoupling effort
by breaking things apart. But what we did is we
increased coupling. Essentially, Now everything was coupled. And if previously
we had to modify one code base, now we had
to modify multiple projects and then synchronize changes, synchronize their
life cycles. Tons of fun. And yeah, it was a
failure atostrophic failure.
Speaker 2: I mean the other the alternative there is that you
run multiple versions of each service. I've gone down that
path where it's like, hey, we're you know, if we
change this API, we're going to affect these other things.
It's like, okay, well let's keep this old one running,
but we'll run a new one as well, and let's.
Speaker 1: Have a service that returns the current versions of all
the services that you should be running.
Speaker 2: That wasn't a problem at all. We were fine, Everything
was fine. That's fine.
Speaker 1: If you had a merge conflict in that service, the
version service service service version service, oh my god, nightmare.
Speaker 2: But you know, I do feel like you're trading plumbing
issues off for monolith issues. Nothing comes for free here. Yeah, absolutely,
where's the balance in this? Because I know it's in
the title.
Speaker 4: Yeah. So, following that experience, that catastrophic failure of that project,
I wanted to figure out what microservices are, how to
design their boundaries properly. And I found the answers I
was looking for in a book that was published in
early seventies. It's called Structure Design, and the answers were
in chapter on coupling, and in it I found some
interesting things that our industry knew in the past, but
we kind of have forgotten it now. So what I did,
what I wanted to do, is to adapt those forgotten
insights to our current technological world, the technologies we are
working on today, and that's how the balanced coupling model
was born. The idea here is that whenever you have
two components, and these components can be anything, whether these
are services, microservices, or two classes interacting with each other,
in order to work together, they have to exchange some
knowledge about each other, like what is your public interface,
what is the format of the data I have to pass?
Or maybe what are the assumptions I have to make
about your behavior? So let's call that knowledge. The second
aspect is the distance between them. Now, if we're talking
about two classes, then their source code is located close
to each other, those are probably the same files and
the same directory.
Speaker 2: Sure. On the other hand, in the same language.
Speaker 1: Yeah.
Speaker 4: On the other hand, if we're looking at two micro services,
then we have much greater distance between those source codes. Right,
greater distance. Now, why we should be interested in it
is the greater the distance, the more collaboration and more
communication effort you need to implement a change that affects
both of them. So I'm going back to that example
from the comment. Once you decompose a monelith into micro services,
you're increasing the distance between those parts of the system.
Those components. Now they're residing in different micro services, so
we have greater distance. And when we look at these
two the mansions, on the one hand, we have the
knowledge that they have to share, and on the other
hand we have distance between them. Then we can deduce
some interesting insights by evaluating their extreme extreme combinations. For example,
if you have a lot of knowledge change across a
big distance, well, that's not going to be foul.
Speaker 1: Right.
Speaker 4: The more knowledge they share, the more cascading changes are
going to follow, Like the more reasons to change together
those components have. Now, when you couple that with the
increased distance. Then we have lots of skating changes, and
we have lots of effort needed to implement each of
those changes. Bottom line, not fun. Or we can look
at the opposite of that. What if we have two
components that are not sharing much knowledge, maybe they are
not even integrated. They're just located close to each other,
so we have low knowledge and low distance between them.
Now what we have is components that are not truly
related to each other, located in the same code, based
the same names, paid the same package module, however you
call it. That's what we usually call the classic modelife
or a big ball of mod You have a bunch
of stuff that is not related, but it's close to
each other, and the next time you have to modify something,
you have to make your ways through those unrelated things
to find what is that class or module that you
do have to modify. And both these relationships high distance,
high strength, high knowledge. I call that dimension of knowledge
sharing integration strength. So once you have high integration strength
and high distance, you have complexity on the overarching system.
If you have low knowledge and low distance, then suddenly
you have another type of complexity. You have cognitive load
that results from you having to struggle to understand what's
going on, what are those things that are implemented in
the same module, and what do you have to modify
when a new business requirement comes in. So those are
two types of complexities. Now, what if we reverse these relationships.
What if we will look at low integration strength, which
means low amount of knowledge shared across a big distance. Well,
big distance means that now we still have to to
invest high effort in implementing cascating changes. On the other hand,
we have that low integgression strength, So there we are
minimizing the chances of those cascading chances a changes happening.
And that relationship is usually what we call a loose coupling.
Speaker 2: Right, and it's what happens most of the time, right
when you're calling in the third party APIs and things
like that. They're all loosely coupled because they are low
distance with low levels of integration. Right, hopefully for long
distance with low levels of integration, they're not inside your perimeter.
They have skate context. Yeah, you know, you've got to
carry your own state like you're not counting on anything,
You're they're external to you.
Speaker 1: Effect ask a question, get an answer.
Speaker 4: Yeah, And the opposite of that is going to be high.
I'm out of an aggression strength high amount of knowledge over.
Speaker 2: Small distance right now local.
Speaker 1: Yeah.
Speaker 4: Now, we do want to minimize the knowledge we are
sharing across the boundaries of components, of course, but it's
not always possible. Sometimes we do have to share knowledge
because maybe we have two components that are implementing closely
related business functionalities, so we have to share knowledge.
Speaker 1: Yeah, maybe they're both injecting the same services, that kind
of thing.
Speaker 4: Yeah, Yeah, there are different levels of evaluating that knowledge.
So let's assume we're on that higher end of the scale,
and there is no way for us to reduce the
amount of knowledge in that case by putting them closer
to each other. We know, we acknowledge that. Yeah, they
will change together, but we are preparing ourselves by minimizing reasy.
Speaker 2: Easy to do that. Yeah, So if I mean I
see the rule emerging here, then this, Hey, these two
things are to be closely tied together, we should make
sure they're close. Yeah, yeah, yeah, and that. In nineties
a model was formulated called connaisance, and in that model,
its author Miller Page Jones use that word proximity to
say that things should be in close proximity to each other.
I prefer the world distance, which is the opposite of
proximity for other reasons.
Speaker 1: Yeah.
Speaker 4: Yeah, but that's so.
Speaker 1: The basic idea is that go ahead and have your
micro services or your services or whatever, but those that
share knowledge should be closer together, and the ones that
should be have more distance, should have less dependency on
each other. Yeah, share share less.
Speaker 4: Knowledge, Yeah exactly, Yeah, and that makes sense. The next
question is how do you evaluate that knowledge?
Speaker 1: Right?
Speaker 4: Yeah, And that's the complicated part, because how do you
measure knowledge? Like what is the management measurement unit for knowledge? Yeah?
Speaker 2: But how much do I need to know?
Speaker 4: Yeah? Yeah, And for that I adapted that model from
seventy's book Structure Design to differentiate between a number of
types of knowledge knowledges. Now, once we're dealing with types,
we don't have to measure the exact amount of knowledge,
because once we're going higher on that scale of types,
the amount is going to be significantly higher anyway. So
overall there are four levels, four basic levels. One of
them is, let's say if we are implementing two components.
Let's say Richard, you're implementing micro service, which means when
I'm integrating with it, I should be using its public interface,
but I'm not going to do it. Instead, I will
reach out to your database directly and take whatever the
data I need.
Speaker 1: Yeah, it.
Speaker 2: Memories make the batman stop.
Speaker 4: Yeah. So what I'm doing here is I'm introducing a
dependency on your implementation detail.
Speaker 2: Right, and I can break you very easily by modifying
my database for my next version.
Speaker 4: Exactly.
Speaker 2: I not know that I did exactly. Yeah.
Speaker 4: That's why let's call this level intrusive coupling. I am
intruding your boundaries.
Speaker 2: I mean in a way that doesn't bother me all
that much, because you're I can break you. You can't
really break me.
Speaker 4: It depends what I'm doing there.
Speaker 2: It's kind of like the beer puts. Yeah, I mean
you can't. You're right, you can by inserting weird data
into my database. Yeah, that you know, can break my
code expecting certain consistency in the database, which is my fault.
I should have had put parameters on my database that
don't allow you to do that.
Speaker 4: Yeah. So that's intrusive coupling. That's the highest level of
knowledge sharing. We're assuming that this is the knowledge you
shared it.
Speaker 2: Yeah, but this seems like I don't do this, this
is bad.
Speaker 1: Yeah, this is only.
Speaker 4: Level one depends let's get back to it.
Speaker 2: Okay, let's get back to it.
Speaker 4: The next level is functional coupling, and here we have
two components that are implementing closely related functionalities. Maybe they're
implementing closely related use cases, but the bottom line is
the wheel have to change together when the business requirements.
Speaker 2: Change, so they resonate together.
Speaker 1: Yeah.
Speaker 4: Yeah, So they have to share lots of knowledge because
once that functional dependency is there, we have to make
an assumption that there will be business rules that both
of them will have to follow. So that's the functional coupling. Now,
there are different degrees of functional coupling. Let's not get
into it because we'll need another hour just for that
sure topic.
Speaker 2: But is it one of the arguments that you should
have been the same service.
Speaker 4: Yes, but let's get back to it later.
Speaker 2: Okay, I'm jumping head.
Speaker 1: Yeah.
Speaker 4: The third level is model coupling. This one means that
we have two components that share the knowledge of the
model of the business domain that are using Now, every
time I talk about this level, I have to wear
my dominion and design guide CAP because it's heavily influenced
by the Clean Dream design. And the thing is, when
we are implementing a system, of course, we are not
coding all the knowledge available about that business domain, but
we have to pick whatever we think is relevant to
solve the problem that we want to solve for the
users of our systems. Right, So we're crafting a model
of a business domain now with new requirements, with new
insights into business domain. That model should evolve over time.
Once we're sharing that knowledge, we kind of reducing our
ability to evolve that model, so it can be problematic
in some cases. That's the third level of integration strengths.
Speaker 2: But models don't change as often as functionality does.
Speaker 4: Well, it depends what kind of system you're working on.
Let's say that you are working for a star up
company and at the first stages there's so much uncertainty
about twitching. Yeah, everything about how we're going to solve
the problem for our customers, and even the problem itself
can change. Yeah, So that's model coupling. The third level, Now,
the lowest one is what I call contract coupling. And
here we have an integration specific contract that was formulated
for integration purposes only. Its goal is to encapsulate all
the knowledge about implementation details, all knowledge about functional requirements,
and of course all the knowledge about the model of
the business domain that's being used to implement the component.
What we want to expose is a much more stable
interface that is not going to be changed after each
new business requirement that comes in something way more stable.
Speaker 2: This is that public API inter face mindset exactly.
Speaker 4: Yeah, yeah, yeah. And if I will bring back my
domain gveing design cap again, then have anti corruption layer,
we have open host service. These parents. What they're doing
essentially is introducing an integration contract for those purposes. So
we have four types of interfaces, contract, model, functional, and interesting.
These are four types of knowledges, and we cannot put
a number to evaluate the amount of knowledge we are sharing.
But knowing these four types already helps us to evaluate
where we are.
Speaker 2: Yeah, at least get people in the categories, right, yeah.
Speaker 4: Now, as I mentioned in the book, there are degrees
for functional model and contract coupling, so that you can
compare to interfaces of the same type. These degrees are
based on the conations model. It has lots of levels,
so it will require another hour.
Speaker 2: Just that topic, by the book is a good number, right,
Like you could probably discribe, especially at the functional level,
you could discriminate a bunch of options in there. But
I'm with you. Four you can feel good about. It's like,
I'm not just thinking that all coupling is bad. I'm
recognizing some is necessary, but some has larger consequences than others.
Speaker 4: Yeah. Now, let's talk about the dimension of space, the
distance between those components. So on the one hand, we
have the code base where the components are implemented. If
the files are in the same directory, the distance is low,
or maybe in the same file even the distance is
minimized versus let's say, different project, different repositories. But there
is another aspect to that dimension, and it's organizational. First.
Let's say that we have two micro services, and we
have two cases. In the first one, both micro services
are implemented by the same team. In the second one,
we have two micro services implemented by different teams. In
the second case, we'll need much higher collaboration and communication
effort to implement a change. So it also affects the distance.
Speaker 2: I mean, I argue it's the same amount of communication
it's just one is easy because you're in the same team,
and one needs more structure because you're not the same.
Speaker 4: Yeah, exactly, So we have that organizational aspect that increases
the distance. And also again going back to the comment
that you read in the beginning of the show, Let's
say we have two components that are imp implementing synchrons
communication between them, and the second case with asynchronous communication
between them. Right now, in the case of asynchronus communication,
we have a bigger distance between them, bigger virtual distance
between them. Let's say that way because we have a
lower life cycle dependency between them.
Speaker 2: Right.
Speaker 4: If we have low distance, let's say components implemented in
the same monolith, then we have that life cycle dependency
between those services. Everything within that MAELD have to be implemented, tested,
and deployed.
Speaker 2: Simultaneously, functionally, but coupled.
Speaker 1: Yeah.
Speaker 4: Once we were introducing that asynchronous communication between them, we
are kind of extending the distance, right.
Speaker 1: Yeah.
Speaker 4: Now, let's go back to the topic of ineggression strength.
Let's say that we have two components share lots of
knowledge between them. Let's say they have interessive coupling between them.
The bad one M and let's assume we have high
distance between them. Is this design necessarily bad?
Speaker 2: I mean, it's got a lot of consequences to it. Yeah, right,
and you need a lot of communicating to move you're
often going to have if you've got a good testing harness,
it's going to fail a lot because you're moving things
that affect the other composers.
Speaker 1: I would ask, why did you choose this model? Oh,
why do you need that?
Speaker 4: That's a great question, So I'll provide you more information
about the context. So here's the thing. I work on
a system that integrates with a legacy system that is there.
This is not going to change ever. Nobody wants to
touch it, so there's no one I can ask to
add new interface to it so that I can work with.
Speaker 2: You're not going to get any changes.
Speaker 1: Got to go directly to the database, that's what you're saying.
Speaker 4: Yeah, so I will do it. But I made that
assumption that that legacy system is not going to change,
right right, Okay, And that's the third dimension of coupling volatility.
Speaker 1: Hey, I think this feels like a good place to
take a break, So hold that thought. Flag will come
right back after these very important messages don't go away.
Did you know that you can work with AWS directly
from your ID. AWS provides toolkits for visual studio, visual studio, code,
and jet brains rider. Learn more at AWS dot Amazon
dot com, slash net slash tools, and we're back. It's
dot net rocks. I'm Carl Franklin, that's Richard Hey Campbell,
and we're talking to Vlatkonanoff about you know, decoupling, coupled, balancing, decoupling,
I think is what we're calling it.
Speaker 2: Yeah, balancing coupling.
Speaker 1: Yeah, balancing coupling or dec degree.
Speaker 2: So you just hit a third dimension there, the volatility
versus the distance, which is not necessarily a physical distance.
It's also are the teams separated or are they on
disparate teams? Might be security boundaries. There's a bunch of
different ways with great separation. And then the level of
interaction or the coupling within the code, how tightly tied
together they are, Yeah, alas sharing, so yeah, they manage
knowledge sharing and the bund scenario you painted there where
it's like, Okay, I'm doing some intrusive coupling on it
in my new app against its existing app, which is
relatively nearby. We're working in the same context, but its
volatility is very low, as in, I'm one of the
reasons I'm doing this intrusive behavior is because I cannot
change the other phase. So that doesn't seem to me
like the lowest thing. It seems like the only solution circumstance.
Speaker 4: Yeah, and that brings us to the title of that
model balanced coupling. Once we have those three dimensions, once
we can evaluate them, we can say, okay, so we
have in aggression strength and we have distance, and we
have to be inversely proportional to each other. Okay, okay,
once one of them gets higher, the second one should
get lower. We can even find some middle ground. We
have middle amount of medium amount of knowledge, then medium
distance is okay too. But sometimes we're needed. We can
be a bit more pragmatic by introducing that third dimension
of volatility. And if components are not expected to change,
those components that are sharing the knowledge, then it can
be okay to allow them to share high amounts of
knowledge across big distances.
Speaker 2: Right. Yeah, and well, and again you get into that
motion of hey, we're finding a lot of coupling between this.
Maybe we need to get this into the same team,
like a lawful lot of complexity would end if we
move that team member on that other team over with
us while this work is going on, and then communication
becomes easier. We can get through this period and decide
what happens from there, as opposed to, Hey, this is
complicated and it's distant, and we can't do anything about
that part, so let's minimize the volatility.
Speaker 4: Yeah, And that's a very interesting comment because in the
book I'm talking about software design. However, we had a
conversation with a friend of mine, a Sonya and Tanzem
about the organizational design, and turns out we can use
the same model to evaluate the design of the organization.
Like if you have people in the same team who
are working on underlated things, which means they're not sharing
much knowledge between them, right, why do we need them
in one team?
Speaker 2: Why? Yeah? Why are in the same team?
Speaker 1: Yeah?
Speaker 2: And the opposite you do you talk about Conway's law,
this idea that the team architecture also tends to dictate
the software architecture effectively, like if you if you have
three teams, you're going to make a three pass parser. Yeah,
that's just how it's going to happen, and now you're
talking about, Hey, as we get to the best architecture
on this, we could start shaping the team structure so
that Tonway's law doesn't fight us.
Speaker 1: Yeah.
Speaker 4: Absolutely, I think.
Speaker 2: That's really interesting. And you've described a scenario now where
you might want to add a team member or even
separate a team. Both scenarios are reasonable, which is probably
a fairly good case. Then it's like, in both cases
you can see why you would change the organization to
reflect that intended art.
Speaker 1: First we fix the architecture, then we fix the team architecture.
Speaker 2: Perhaps, Yeah, I mean I think there's going to be
an oscillation back and forth, Like we don't always see
that these two things are going to end up coupled,
right as that as they requirements e merge and you
start seeing this is more and more and more coupled,
you might have as anario where it's like, yeah, okay,
we should probably bring these things together, but this participant
can't necessarily join that team in easily. Should we change
the team member into somebody you know, switch who's going
to work on that into someone in that other team,
because it'll make all of these other things easier, Like, yeah,
that's an overhead too to change team members like that,
but it might be less expensive than continuing in the
current the current layout.
Speaker 4: Yeah, And as they say, organizational design always wins, right,
So we need that that way of evaluating the type
of knowledge that is being shared, whether it's across technical
components or across teams or team members.
Speaker 1: Yeah, it's easier to change code than people.
Speaker 2: But sometimes it's more efficient to change the people if
you can, Yeah, if you can. Like what I like
is we've created a reason to have that conversation. Yes, Like,
when I think in terms of balance company and balancing
these three numbers, one of the options suddenly becomes do
we change the team to compensate with this problem? Is
that even a possibility, because sometimes that'd be a very
easy solve, Like that person's always wanted to be on
that team, and now we have a good reason to
put them there, at least introducing that factor, like the
idea that we're going to use conways a lot in
our favor, and we're going to shuffle the team to
increase the quality of software. That's slick, man, that's good thinking.
Speaker 1: It's been my experience, Richard, maybe years two and laid
for that matter, that it's easier to add people to
a team than to remove them, sure enough from a team,
and people don't like being removed.
Speaker 2: I find depends on the person. But also like you
can work into more independent you don't need to be here.
Speaker 1: Yeah, there's another team we want you to be on
because it'd be more effective there, and that kind of thing.
Speaker 2: Yeah, this is the personality thing. But I just liked
that you could put it on the table now in
a coherent way. It's not political. I'm not after that
person or anything like that. I see an issue in
our architecture that is going to lead to consequences, and
maybe a change of team would mitigate that.
Speaker 1: Interesting.
Speaker 2: Yeah, I know, I'm shaking up. I'm excited. Thanks, Flat,
that's really interesting. That's a great way to talk about this.
Speaker 1: Cool.
Speaker 4: Yeah, it's important to have a framework to formulate these
kind of things. But yeah, you know, when I decided
I want to be a programmer, they told me that
you're going to work with computers, not with people. Biggest
lie of the century.
Speaker 2: Big lie totally turned out. People use the software and
it ruins everything.
Speaker 1: I know, if you just get rid of the people,
chopped so much.
Speaker 2: Yeah, you know, as long as nobody uses software, it
works great.
Speaker 1: I wonder why. That's why you have front end developers
who like people and back end developers who don't like people.
You know, people become DBAs because they just want to
talk to the database. That's it.
Speaker 2: But I do have to talk to people. I get
to say no, no, no, you can't, no, you can't.
I'm sorry, we're digressing. There's more to this story. I
think you need to continue about it.
Speaker 1: But you know, you open a Pandora's box though. If
you know architecture for both the teams and the code
has to work hand in hand. It's definitely Conway's law
applies here.
Speaker 4: Yeah, yeah, absolutely absolutely, And the two are interconnected. And
that's what I love about that dimensional distance is that
it reflects it. It reflects organizational desig even though you're
looking just at the code.
Speaker 1: So you're a consultant. You go into a company and
they have some horrible monolithic thing, or maybe they've got
micro services whatever, But you see the problems that you've
outlined here, and how do you go about convincing them
about this kind of stuff without sounding too academic? Right?
I mean, this is pretty technical stuff you're getting into here, right,
You've got formulas and stuff, and maybe you have some
stories from your experiences dealing with customers and how they've
worked around it.
Speaker 4: Yeah. So the most common story is one of a
company that wanted micro services and ended up with distributed monelith,
and the hardest thing is to convince them to bring
back everything into the same code base, to redesign it
over time into a modular monelith, and then rebreak it
into micro services.
Speaker 2: Interesting. Yeah, that doesn't seem like the right path, but
I can see why it would be right.
Speaker 4: Yeah, because once you have it in the same code base,
you have shorter distance, which means it's easier to change,
to change things together.
Speaker 1: If you need to. Productivity goes up. Yeah.
Speaker 4: Now you re evaluate the boundaries of those services micro
services that you want to build, and once they have
that logical form of modules within the same model, if
it's okay to be wrong, that's right, a mistake that
is really easy to fix.
Speaker 2: But you're also doing this very empirically. You know, if
you assemble them, they'll gather some momentum and life will
be easier for a while, but eventually you're going to
have a production issue of some kind that sort of
points to, here's a piece of code that's resonating and
if it were separated, it would cause less residence.
Speaker 4: That's true. Yeah, that's true, But there are different ways
to There was a company I was working with. They
had that code base which was monolithic, but it was
still deployed as different services for that reason, not sually.
For that reason, they needed different levels of scale for
different components of that system. So the underlying code base
is monolithic. Whatever there is change like new deployment, we
already deploying all the services together like no exceptions, but
still were able to gain the benefits of a lower
cost of a design mistake and that advantage of kind
of reducing the operational the cost of operational failure.
Speaker 1: Give me a story of where you found difficult people
who dug in their heels and said, you know, I
separated out these micro services because I read such and
such a book and you know this is sound architecture
and you don't know what you're talking about, and you know,
meanwhile it's really slow and brittle. I mean, how do
you deal with people like that?
Speaker 4: So usually when they call me, these people have already
left the company. Ah really, well, maybe they were promoted
so that they.
Speaker 1: Yeah, Gilbert Principle failing upward and moved to management.
Speaker 2: There you go.
Speaker 1: Yeah, I see, but you you have obviously at some
point experienced and pushback, right of course. Yeah.
Speaker 2: But at the same time, they're not calling you because
things are going well.
Speaker 1: Yeah.
Speaker 2: Yeah, they never called me for that. It's like, hey,
I wanted to pay your fee and bring it in
for a week just to show you how well everything's going.
Speaker 1: I think about Robert Irvine and restaurants impossible. How he
goes into these failing restaurants and they dig in their
heels and says, my food is great, and it's like, yeah,
I can tell your one customer loves it.
Speaker 4: Well. You know what, if we're talking about pushbacks, then
I'll bring back the topic of domain dreaming design because
for some reason, the main driving design it's got this
reputation of being too complex, with too much, too many
patterns and if you apply them.
Speaker 1: Driven because it makes your foot look big and it's
a it's a pistol, you know.
Speaker 4: Yeah. Now, once you face that kind of pushback, what
I usually do is I started talking about the principles
of domain dreaming design without mentioning domaindreamine design without mentioning
concrete patterns like Okay, so we have this problem that
we have to address. So that's the root cause of
the issues you're facing. Now, maybe you want a brainstorm
what we can do. And there was a guy that
invented the aggregate pattern with a different name, but he
was so happy, and I said, okay, cool, let's go
on with it. Call it what a you wanted.
Speaker 1: Yeah, yeah, yeah, Bob's pattern.
Speaker 2: But yeah, you know it's people have their biases. So
if you leave the words out but still do the
work and get results. And maybe he retroduced the word later,
but it's not even important. The goal was to get solved,
so just find a way to get forward. The principles
are still their useful principles for some reason.
Speaker 4: I don't know why, but this model of balanced coupling
is way easier for people to grasp and to start
using them. Domain dum in design, Yeah, I mean always
compared with do major in design.
Speaker 1: I'm getting that. Yeah, I'm getting that. Four levels. That's
all you need to know.
Speaker 2: Yeah, just that conversation of sorting your problems into these
different categories and then saying and then you have it
approach strategy for each one. It's different.
Speaker 4: Yeah, and if you look into pretty much almost all
patterns from domain dreaming design, they have that balancing behind
the scenes. If you have, for example, Eric Evans always
says that not all of our system is going to
be well designed. It means that supporting subdomains are not
that important. It's okay to around some corners. What about
supporting subdomains. They're not business critical, so they're not going
to change that much, which means their volatility is going
to be much lower than core subdomins. So again we're
getting that balance. We can introduce some complexity because we
have lower volatility, but when we're talking about high volatility
of course subdomains, then yeah, we should keep things as
well designed as possible. Sure we have those patterns for
encapsulating models in bounded contexts, etc.
Speaker 2: You're also learning to pick your fights right. You get
people together that be architecturally absolutist in everything has to
be built the same way, where by going through this
coupling practice and figuring out what's actually going to be problematic,
only fight for the ones that are going to have
the biggest harm if they are done poorly. The edge
cases can be a little can be weaker because the
consequences are small. But where the consequences are big, then
you can push harder and spend more time, even do
spikes to evaluate how couple this is really going to be.
What are the consequences of separating it? Like, it's worth
spending time on that, just you don't have to do
it for everything.
Speaker 4: Yeah, and volatility, that dimension of changes or dimension of
time helps a lot here because once you spot the
high volatility. By the way, how do you evaluate volatility
and different ways different models. I prefer the management design subdomains.
And once you spot a high volatility, then yeah, you
have a low hanging through there things that first.
Speaker 2: Yeah, Well, and it also speaks to when we're going
to sign a new piece of this app and we
see high volatility. Now I certainly have a new opinion
about where should it reside based on where what the
coupling looks like. It's like, you know, at least initially,
I think we should start this in this team where
it's close to all the pieces it's going to touch.
You know, if that changes, we can revise that but
for the moment, especially when say the design is immature,
it's a new area, Minimizing distance takes a lot of
risk off the table.
Speaker 1: Yeah.
Speaker 4: Well, let's be honest here, it's not always possible. Sometimes
when you minimize the distance, you are introducing accidental complexity, Right,
So I always strive for at least logical boundaries within
that monolith. Sure, and then we have that distance. It's
going to be significantly lower compared to the initial distribute monelith,
of course, but still we can talk about different distances
within that code base, within that monelith. If we're looking
at the same module, the same logical boundary, the distance
is lower compared to different logical boundaries within it.
Speaker 2: Yeah, I appreciate that. That's good.
Speaker 1: Yeah, So is there anything else that you want to
cover before we say goodbye? Any shout outs or anything
shut outs?
Speaker 4: Not surely. I just want to remind again that there
is more to it. There are degrees for the three
levels of integration strength.
Speaker 1: Right, that's the one you said would take another hour
to explain.
Speaker 4: Yeah, they provide more detail and they also kind of
help you to identify those specific cases, whether it's functional
coupling or model coupling.
Speaker 1: All right, well, Vlad Honenoff. His new book is Balancing
Coupling and Software Design. Go check it out. It's a
fascinating subject and we've already had our eyes open. And
thank you Vlad for talking to us today. Thank you
so much for having me bet all right, we'll talk
to you, dear listener, next time on dot net rocks.
Dot NetRocks 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.
Speaker 3: 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.
Speaker 1: 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 your middle.
Speaker 1: Vands do the same. This is hard than my Texas