Balancing Coupling in Software Design with Vlad Khononov
50:00 Share

Looking for excitement, jumbo casino is here. Play anytime, play anywhere, play on the train, play at the store, play at home, play on your board, play today for your chance to win and get daily onur log in is free to play. Experience a game play like before chAmbers o right now to play hundreds of games, including online, lots lingo and more, live the chAmber life at chAmber caso 点 com。 Seditions eating class .

black friday is coming. And for the adults in your life who love the coolest toys, well, there is something for them this year too. Martin is the premier craft cocktail maker that automatically makes more than sixty seasonal and classic cocktails each.

And the thirty seconds at the push of a button. And right now, but teaching is having a huge cycle de sale. You can get one hundred dollars of any cocktail making or cockpen le when you spend four hundred dollars more. If cocktail lover in your life has been good this year, all the right kind of bad, get them about tea at the push of a button, make back quality Cosmopolis, marti, manhattan s and more, all in just thirty second, all for one hundred of amazing toys are just for kids. Get a hundred of a cocktail maker when you spend four hundred to cyber monday visit about teaching dot com flash cocktail, that B A R T E S I A N dot com flash cocktail.

how you like to listen to that net rocks with no ads. easy. Become a patron for just five dollars a month.

You get access to a private R S S. Feed where all the shows have no ads. Twenty dollars will get you that end, a special dot net rocks patron mug. Sign up now at patron on t dot net rocks dot com.

Hey, welcome back to dot and rocks. I'm carl Franklin .

and i'm mature candle.

We are here for your dot net pleasure and .

any other pleasure you want. But you know, don't get crazy. No.

i'm gonna limit .

to dot net that okay.

maybe geek up pleasure, maybe little science. Yeah.

i'm right. My end year geek outs, man. It's it's a pile work, but working on them.

that's great. I can't wait to, can wait to hear him. Yeah all right. Well, let's get started with a little thing we call Better know a framework.

right.

So I went looking to see what's trending as far as sea sharper, posit orison, github. And one that has recently got a lot of activity or a lot of coolness is tom hursts tea unit, a modern, fast and flood able dot net testing framework. Now I haven't never used IT.

I don't know anything about IT except what IT says in the in the reao, which is that its modern and fast tea unit leverages source generators to locate in register. Your test is opposed to reflection. nice.

You'll have a sleep bump in build time at a speed er runtime. T unit also builds upon the newer microsoft testing platform. As microsoft dot testing platform, whether most other framework you'll have to use, you use will use VS test. The new platform is reconstructed from the ground up to address pain points, be more extensible and be faster.

So this is just to play on x unit, but excute depends on the reflection. And here they're using analyzer system yeah some sort of modernized contort of modernized yes, 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, gra B2Come to eve r sho wed nin eteen, sixteen. So that's the one we did with render right back in september show I called how simple is as simple as possible, right? So I mean, does this smart person, right? Like just think about development really coherently and and very typical of know how do we do the right thing, the right way and he kicked off autonomic ments, lots of people reacting to the show.

And cash bon fill said this. He said, this is a really interesting showing. If his writing discussions we're currently having at work with a team of eight developers altogether, so hardly the size of netflix.

X, that's okay, man. You don't be decided. Netflix of problems. We are building a lot of microwaves because we can. It's all good, but IT comes at the Price. One example is that we are making everything a synchronous that is with service bus integrations in the form of topics and cues.

Again, all good on April because every time we have acing communications betwen, our very small services, we have situations where things don't work out as IT was supposed to measure, end up on D, L, Q. And someone or something has to monitor and compensate. All of a sudden we start building in points and handles, have allow messages to be fixed and rerun.

So are spending our precious time creating things to compensate for architectural and infrastructure things, instead of actually building business value, right? My point is that on an architecture, drawing a simple straight line might end up being insanely complex. Another funny thing, we started using deer.

That's D, A, P, R, for the exact reasons that mandel mention ons. Eventually we left IT again, and IT turned out to have be a horrible developer experience. Dep is another great example of being a good idea from an architectural point of view, but implementing IT IT was a nightmare.

Pretty sure will improve in the future. But the moment it's too mature from a developers point of view. Thank you for the great show. I always feel like I having a biscuit and a cup of tea when you have rental absolutely .

or some fish and chips and stout more like and it's .

doubt out and much peace for sure yeah you can keep the know it's actually that you're gone down that path and you're seeing the struggles around all of bit. And again, it's like because you can think problem now is that the architecture would be an interesting chinese and there shouldn't be that tough.

You already done the hard work separating concerns, now you want to put some one back together, but great to to hear the experiments going on and the chAllenges they are in. You're pretty big team. I mean, eight people's enough that, that abilities put the workshops pretty cold. So cash, thank you so much. You are comment in a coffee used to coby is on its way to you if you'd like a coffee music coby, write a comment on the website at the net rocks saw comment on the facebook we publish ever show there and if you comment there are in a meeting on the show, i'll think you cope your music code.

or if you feel like buying musi C2Code, how you go to musi C2Code by the net and you can als o fol low us on x t wi tter. Of course, we've been there for years, but cool kids are hanging out. I'm masted on.

i'm at carl Franklin attack, have that social and i'm rich camel.

Let massena to Richard. Before we get started here, I realized that that I didn't do my, you know what happened in one thousand, nine and twenty three?

This is show twenty.

and we have to because my usual page that we go to is down for some reason. But just pick a few here. January fifth, live wini begins the clipper revolt to anx the client region.

I don't know. I know this is pretty world war two, right? So you're talking about the four sort of the fall out of the of the automated empire, and it's crazy this for sure.

March first, econ, the largest electricity producer in africa, is established in south africa. March third, the first issue of time magazine is published. Wow, let's go.

March ninth, vlama lennon suffers his third stroke, which renders him bed written in, unable to speak. Consequently, he retired from his position as chairman of the soviet government. Let's see british prime minister in may bone, our law resigns to the ill health.

And I know 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 rust stove in the soviet union.

Oh my wow. That's that. Those are big health stone of the killing people. Yeah.

like twenty of punch of v is assassinated. Her dog, the Apollo. The treaty of lucene is a signed setting the boundaries of moving republic of turkey in switch, right? I would argue the big .

thing in twenty three is the beer hell push. Is that the beginning of the the first crew attempt by hit lynn and his go court horse that fail beer house pushed your hat.

pushed opp o hard poch. In november eight, in munich's alfy, their leads and nations and an unsuccessful attempt to overthrow the bavarian government, police and troops crashed the attempt. The next day, twenty people died as a result of associated violence, and our friend Christian wire was not born yet.

No, but he 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.

Yeah, I don't know why you brought that up. Is there some sort of an event something that you're referring to?

I'm not referring anything, referring to things. I don't know what you're talking about.

I don't know what you're talking about either. okay. All right, let's bring in our guest, vlad. Honor off 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, untangle monoliths and address complex architectural chAllenges.

In twenty twenty one, vlad published learning domain driven design, followed by his latest book, balancing coupling in software design, released earlier this month as a public speaker. Lad presents a conferences worldwide on topics such as software architecture, domain driven design and distributed systems. And I believe this is his first time on dot net rocks.

So welcome, fat. Thank you so much. It's such an here .

you heard of our .

show yeah that I started listening to you two thousand six, I believe ww, and then you spoil the experience of listen to other podcasts for me because doesn't quality expected .

from the rest of them.

We've always taken the engineering side of the show very seriously. Yeah the content we have more fun, but quality audio is.

Important .

content quality went way up when Richard join the team.

That's for sure. That's a long time and it's come upon twenty years like in a few months.

Yeah, yeah. And remember that series lapse year that we had before you came on where we started doing comedy and two hour shows. And what were we thinking who have was IT.

IT was a variety show. And remember talking to about this. So there's a one diagram here.

There's a diagram of folks one of technical interview and folks who wants like music and dik humor and all those sense. And the intersection is small, but the two big other circles are big. Why do we just home apart? Just right. So one days was born, road shows got bigger.

OK lad, enough about us. Let's talk about you're experiences untangling monodist and getting the baLance of complexity, right? What are you talking about?

yes. So actually the common that Richard red, that experience sound that 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 moneth. IT was a moneths cold base. So he said, okay, let's make IT Better by breaking IT down into microsoft. Or another words lets the couple things. So we introduced towns of services that we call the microphone, of course, with a six 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 microwaves because they have nothing to do with microphone yeah I don't know how.

I mean, how do you call it's only micros if you put that in the comments? Like I don't know the difference, it's just the service.

Yeah, the thing is they are 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 you know is is still gonna be robust.

Yeah, yeah. And again, I started with that decoupling effort by breaking things apart. But what we did is we increase cubbing essentially.

Now everything was coupled, and if previously we had to modify one code base, now we had to modify multiple projects and then synthesize changes synchy. Ze, there are life cycles, tonnes of fun, and the IT was fatal, catastrophic failure. I mean.

the other, the alternative there is that you run multiple versions of each service. I've gone down that path or like, hey, where you know if we changes C, P, I, we're going to affect these other things just like, okay, well, let's keep this old one running, but will run a new one as well.

And let's have a service that returns the current versions of all the services that you should be running.

That was no problem at all. We were fine. Everything was fine. it's.

If you had a merge conflict in that service, the version service service service service oh, my god, may.

But you know I do feel like you're trading plummers issues off for monolithic es. Nothing comes for free here. Yeah.

absolutely. Where's the .

baLance in this? Because I know it's in the title.

yes. So following that experience, that catastrophe failure of that project, I wanted to figure out what microwaves are, how to design their bounders properly. And I found the answers that I was looking for in a book that was published in early 7 monies is called structural design。 And the answers were in charter, on coupling.

And in IT. I found some interesting things that our industry new in the past, but we kind of forgotten now. So what I did is, what I wanted to do is to adapt those forgotten insights to our current a technological world with technologies we are working on today. And that's how the baLances coupling model was born.

H, the idea here is that whenever you have two components, and these components can be anything, whether these are services, microsoft, to classes, interacting with each other, in order to work together, they have to exchange some knowledge about each other, like what, what is your public interface? What is the format of the data I have to pass, or maybe what are, 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 are talking about two classes, then their code is located close. Teacher, those are probably the same files in the same directory with other hand .

in the same language.

yeah. On that hand, if we looking add to microwave, then we we have much greater distance between those source calls, right? Greater distance.

Now why why we should be interested in 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 monos into microwave, you are increasing the distance between those parts of the system, those components. Now they're residing in different microbes. So we have greater distance.

And when we look at these two dimensions, 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 reduce some interesting insights by evaluating their exam extreme combinations. For example, if you have a lot of knowledge exchange across a big distance, well, that's not going to define right.

The more acknowledge they share, the more cases ing 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 skiing changes and we have lots of effort needed to implement each of those strangers.

Bottomline, not fun. yeah. Or we can look at the opposite of that.

What if we have two components that are not sharing much knowledge? Maybe if they are not even integrated, they are just located close teacher. So we have low knowledge and low distance between them.

Now what we have is components that are not really related to each other. Located in the same could base the same name spaces, same package module however you called, that's what you usually to call the classic movies or a big bowl of money. You have a bunch of stuff that is not related, but it's closely each other.

And the next time you have to modify something, you have to make you wait through those, our later 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 the dimension of knowledge ging integration strength. So once you have high immigration strengths and high distance, you have complexity on the over russian system.

If you have no knowledge and well distance, then how do 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 implement in the same module? And would 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 in aggression strength, which means low amount of knowledge shared across big distance? Well, big distance means that now we still have to to invest high effort in implementing the skating changes.

On other hand, we have that low integration sion strength. So there we are minimized ing the chances of those as skating chances. Aid changes happening. And that relationship is usually what we call loose coupling.

right? And it's what happens most of the time, right, when you're calling into third party apps and things that that they're all loosely coupled because they are low distance with low levels of integration for fully for long distance with low levels of integration. Yeah not inside your perimeter. They have a small you've got to Carry your own state like you're not counting on anything they're external .

to you affected ask question.

get any answer yeah. And the opposite of that is going to be high out of an aggression strengths, high out of knowledge over small distance right now. Yeah, now we do want to minimize the knowledge we are sharing across the borders 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 and related business functionalities. So we have to share .

now and maybe you're they're both injecting the same services.

that kind of thing. Yeah, yeah. There are different levels of evaluating that knowledge. So let's sume.

We are on that higher end of 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, yet they will change together. But we are preparing arose ls.

by minimizing and to do that. yeah. So if I mean, I see the rule emerging here, then this, hey, these two things are, be closely tied together, we should make sure their clothes.

yeah, yeah, yeah. And the in nineties, and a model was formulated, a cold connection. And in that model is after millbay Jones, use that war proximity to say that things should should be enclosed proximately to each other. I prefer the word distance, which is the opposite of proximity for other reasons. Yeah, yeah, but that's so.

The basic idea is that go ahead and have your microphone or your services or whatever. But those that share knowledge should be closer together, and the ones that should have more distance should have less dependency on each other. Yeah, less knowledge.

Yeah, exactly. The expression is, how do you evaluate that knowledge? Yeah and that the complicated part because how do you measure knowledge? Like what what is the manager measurement .

unit for knowledge? yeah.

But how much do I need to know? yeah. yeah. And for that, I adopted that model from seventy's book structure design to differentiate between a number of types of knowledge knowledges.

Now, once we deal with types, we don't have to measure the exact amount of knowledge because once we are going higher on that scale of types, the amount is going to be significantly higher anyway, right? So overall, there are four levels, four basic levels. One of them is, let's say, we are implementing two components. Let's say, Richard, your implement microtest, which means when i'm innovating with IT, I should be using its public interface, but i'm not going to do IT. Instead, I will reach out your data based or happily and take .

whatever the data I yes.

Please make the bad man stop.

Yeah so what i'm doing here is i'm introduction and dependent .

on your implementation here and break very and not know that I did exactly .

yeah that's why let's call this level intrusive coupling. I am including your bounders. I mean.

in a way that does not bother me all that much because you're I can break you, you can't really .

break me IT depends what i'm .

doing that like the beer push.

I mean, you you're right. You can buy we are data into my database. ase. Yeah that you know can break my co that expecting certain consistency in the database, which is my I should have had the parameters on my database that don't allow you to do that.

Yeah so that's interested. Ve coupling that's .

the highest level of not. So yes.

it's on the level.

One depends. Let's get back to okay, let's get back to the next level. Ease, functional, comply. And here, we have two components that they are implementing closely related functionalities. Maybe there are implement closely related use cases, but the bottom is they will have to change together when the business requirements change.

So they together.

yeah yeah. So they have to share a 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 a different degrees of functional coupling. Let's not getting to IT because we'll need another hour just for that sure topic .

but is one of the arguments they should have been the same service yes.

But let's get back .

to later. I've judge .

had yeah 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 they are using. Now every time I talk about this level, I have to wear my domain gim and design a guy cap because is heavily influenced by the lander room design.

And the thing is, when we are implement a system, of course, we're are not coding old and knowledge available about that business domain, but we have to pick whatever we think is relevant to solve the problem that we wanna solve for the users of our systems, right? So we are crafting a model of a business man 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 this model. So IT can be problematic in some cases. That's the third level of in the great strength.

It's but models don't change as often as functionality does. Well, IT depends .

what kind of system are working on. Let's say that you are working for a stark company. And at the first stages, there are so much uncertainty .

yeah about .

everything about the how we are going to solve the problem for a customers and even the problem itself can change yeah. So that's model comping. 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 knowledge about implementation details, old knowledge, knowledge about functional requirements, and of course, all analogy about the model of the business domain that is being used to implement the component we wanna expose is a much more stable interface that is not going to be changed after each new business requirement that comes in something very more stable.

This is that public A P. I interface .

mindset. exactly. yeah. And if I will bring back my image and design cap again, then we have. And the corruption we have.

But open host service, these parents, what they are doing essentially is introducing an integration contract for those purposes. So we have four types of interfaces, contract model, functional and intrusive. These these are four types of knowledges. And we cannot put the number to evaluate the amount of knowledge wearing, but not these four types already helps us to evaluate where we are. Yeah.

please get people in the categories right.

yeah. Now 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. If these degrees are based on the canadian model. IT has lots of levels, so IT would require another other. Just that topic by the four .

is a good number, right? Like you could probably discriminate like especially the functional level, you could discriminate about options in there. But i'm with the four, you can feel good about slim. I'm not just thinking that every all coupling is bad. I'm recognizing sum is necessary, but some has larger courses .

and others now is like about the dimension space stance between those components. So on the one hand, we have the cold base where the components are implemented. If the files are in the same directory, the distances low or maybe in the same file given the distance is minimized versus, lets say, different process for repositories.

But there is another aspect to that dimension and its organizational. First, let's say that we have to and we have two cases. In the first one, both micros ices are implemented by the same team.

In the second one, we have two microsys implemented by different teams. Yes, in the second case, we need much higher collaboration and communication effort to implement the change. So IT also affects the distance.

And I argued the same among communication. This is one is easy because you're in the same team and one needs more structure because you're not the same.

Yeah exactly. So we have that organizational aspect that increases the distance. And also again, going back to the common that you right in the beginning of the show, let's say we have two components that are implement, implementing a sync communication between them.

In the second case, with a synchro communication between them. Right now, in the case of acing current 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, right? If we have low distance, let's say, components implemented in the same motive, then we have that life cycle dependency between those services. Everything within that my life have to be implemented, test IT and deployed simultaneously.

function coupled. Yeah.

once we are introducing that a communication between them, we are kind of extending the distance right now. Let's go back to the topic of integration strength. Let's say that we have two components share lots of knowledge between them.

Let's say they have. Injuries of coupling between them, the bad one. And let's assume we have high distance between them. Is this design necessarily bad? I mean.

it's got a lot of consequences to IT. Yes, right? You need a lot of communicating to move. You're often going to have if you've got a good testing harness, is going to fail a lot because you're moving things that .

I think I would ask, why did you choose this model? Oh, what do you need that?

That's a great question. So I will provide you more information about the context. So here's the thing i'm working on, a system that in integrates with legal system, that is there IT is not going to change ever. No, nobody wants to touch IT. So there is no one I can ask to add an new interface .

to IT .

so that I can work with.

I do IT, but I may assumption that, that legacy system is not going to change right now. And that's the third, the dimension of coupling volatility.

Hey, I think this feels like a good place to take a break. So hold that thought. Flad will come right back after these very important don't away did you know that you can work with AWS directly from your a provides tool kits for visual studio visual studio code and jet brains writer learn more at AWS dot amazon dot com slash net slash tools hello .

IT is ryan, and we could all use an extra bright spot in our day, good way, just to make up for things like sitting in traffic, doing the dishes, counting your steps on the monday e stuff. That is why i'm such a big fan of trump, a casino champ. A casino is all your favorite social casino style games.

You can play for free anytime, anywhere, with daily bone to sign up. That's champ. A casino dcom sponde by a caso V G W group ford were prohibited by law.

Eighteen plus terms and conditions apply.

And we're back. It's dot net rocks. I'm called Franklin Richard a cambell and we're talking to lat han and off about you know the coupling a coupled balancing decoupling I think is what we're calling the .

balancing coupling .

yeah balancing coupling or degree.

So you just hit a third dimension there, volatility versus the distance, which is not necessary, a physical distance that's also are the team separated? Are they on desperate teams? Maybe security boundaries was a different, different ways with great separation. And then the level of interaction or the coupling within the code, how tightly tied together they are.

Yeah, now was sharing so yeah .

not they managed knowledge wing and the bonds and area you painted their words like, okay, i'm doing some inches of coupling on an in my new APP against this existing APP, which is relatively nearby. We're working the same context but it's voltige ties very low IT as in I am one of the reason doing this interest of behaviors because I cannot change the other code. So that doesn't seem to me like a lowest thing. That seems like the only solution .

and circumstances yeah 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 integration tion strength and we have distance and we have to be universal proportional to each other OK OK. Once one of them gets higher, the second one should get lower.

We can even find some middle ground. If we have middle amount of medium amount of knowledge than medium distance is okay too. But sometimes we needed we can we can be a bit more pragmatic by introducing the third dimension of volatility. And if components are not expected to change those components that are sharing the knowledge, then IT can be OK to allow them to share high amounts of acknowledge across big distances.

right? Yeah and well and again, we get to that motion of, hey, we're finding a lot of coupling between this. Maybe we need to get this in the same team like a lot of a lot of complexity would end if we move that team member on another team over with us.

While this work is going on and the communication becomes easier, we can get through this period and decide what happens from there. 哼 um as opposed to， hey, this is complicated and it's distant and not and we can't do something about that part. So let's minimize the volatility.

Yeah and that's a very interesting common because in the book i'm talking about software design. However, we had a conversation with a friend of mine, a sona tanza, 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 thing who are working on other later things, which means they are not share, much acknowledge between them.

right? Why do I need .

them in one team?

Here you do, you talk about conveys law, this idea that that the team architecture also intends to dict the software architecture effectively. And I give you, if you have three teams, you're going to make a three past poor yes, 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 time way's lot doesn't fight us.

Yeah absolutely.

That's really interesting. And and you ve described this scenario now where you might want to add ty member or even separate team number. Both scenarios are reasonable, which is probably a very really good case that it's like in both cases, you could see why you changed their organization .

to reflect that intended. Our first we fixed .

the architecture, then we fix the team architecture perhaps to be a olam back. And we don't always see that these two things are going to end up couples, right, as the, uh, requirements emerged and you are seeing this is more and more and more couples, you might have a an area where it's like, yeah, okay, we should probably bring these things together, but this participant can't nessy join that team in easily. Should we change the team member in the somebody switch who's going to work on that in to someone in the other team because it'll make all of these other things easier like, yes, that's an overhead two to change team members like that. But IT might be less expensive than continuing in the current the current lao.

Yeah, 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 take components or grass teams or team members.

Yeah.

it's it's easier to change code than people.

but sometimes it's more efficient to change the people if you yeah, if you like. What I like is we 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 comment, save this problem? Is that even a possibility? Because sometimes that be a very easy soul, like that persons 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 law our favor and we're going to shuffle the team to increase the qualities of that's slick man.

that's good thinking. It's been my experience, Richard, maybe yours too. And lad, for that matter, that it's easier to add people to a team, them to remove them.

Turner, from a team. People don't like being removed. I find pens.

the person, but I also like, you could work IT and more independently.

You don't need to be here. You know there's another team we want you to be on d because you be more effective .

than that kind thing yeah yeah the personality thing. But I just like you could put IT on the table now in a cohere way. It's not political, 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 would mitigate that. interesting. No, i'm shaken up.

I'm excited. Ah bag flat. That's really, really think that's a great way to talk about this.

Yeah, it's important to have framework to formulate this kind of things. And yeah, you know, when I decided that wanna be a programmer, they told me that you are going to work with computers, not with people. Biggest lie of central.

Turned out people use the software and IT ruins everything.

Now we can .

just get rid of the people. 是 凭什么 精神。

什么 记性？

You know， as long as nobody use this software, are IT works great.

I wonder why? That's why you have front developers who like people and back and developers who don't like people. You know, people become D, B, S, because they just wanted talk to the database.

That's IT. When I do have talked to people, I get to saying, no, no.

no, you can. No, you can.

I'm sorry, we're digressive ah there's more to the story continue.

You open a por box. Architects for both the teams and the code has to work and in hand. It's definitely conways law applies here now.

Yes, absolutely, absolutely. And the two are intact, connected. And that's what I love about the dimension of distance， is that IT reflects IT reflects organizational design even though we are looking just at the cold.

So you're consulting you go into a company and they have some horrible thing or maybe they've got micropolis, 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 formula and stuff. Maybe you have some stories from your experiences dealing with customers and how how they worked around IT.

yeah. So the most common story is one of company that one of microsys end up ended up with distribution of model th. And the hardest thing is to convince them to bring back everything into the same cold base to redesign IT over time into a module model th, and then rebreather into microsoft.

interesting. And that doesn't seem like the right path, but I could see why I would be right yeah.

Because once you have IT in the same code base, you have short, shorter distance, which means it's easier to change, to change things together .

if you need .

to do yeah now you evaluate the boundary of those services, microwaves that you wanna build and once they have that logical form of modules within the same olive, it's okay to be wrong. That's right, a mistake that is really easy to fix.

But you're also doing this very empirical. You know, if you assemble them, they will gay other 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 hear a piece of code dents resonating. And if I was separated, IT would cause less residents.

That's sure. Yeah, that's true. But there are different ways to. And there was there was a company I was working in with, they had that cold base, which was moni think, but I was still deployed as different services, right? For that reason, not really for that reason.

They needed different levels of scale for different components of the system. So the underline code base is mollifies. Whatever there is change, like new deployment, we are redefine all the services together, like no exemptions, but still were able to gain the benefits of a lower cost of a design mistake and that advantage of a kind of reducing the Operational because of Operational failure.

Give me a story of where you found difficult people to dug in their heels and said, you know, I separated out these microbes because I read such in such a book in this is sound architecture and you don't know what you're talking about. And you meanwhile, it's really slow and brittle. I mean, how do you deal with people like that?

So usually when they call me, these people have left the company.

Stopping really well.

Maybe they were promoted so that they .

can yeah .

Albert .

principle fAiling upward move to manage .

yeah I see. But you have obviously at some point experience and push back, right? Of course.

Yeah but the same time they're not calling you. Things are going well. Yes, I, yes, they never called me for that. Hey, wanted to pay your fee, bringing for a week just to show how well everything I think about robbert.

irvine and restaurant impossible, how he goes into these fAiling restaurants and they dig in their heels and says my food is great, was like, yeah, I can tell you one customer loves.

Well, you know, if we are talking about push bags, then i'll bring back the topic of domain driven design, because for some reason, the main jamin design got this reputation of being too complex with too much, too many patterns.

And if you if IT makes look and know yeah .

now once you face that kind of push back, where I usually do is I started talking about the principles of domain drain design without mentioning the main driven design, without mentioning concrete patterns. 嗯， like, okay, so we have this problem that we have to address. So there's the root cause of the issues.

Your now maybe you want a brain storm 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 to that call. IT, whatever you want.

Yes, yeah, bob's pattern. But yeah, you know, it's people have their biases. So if you leave the words up, but still do the world and get results, then maybe really forward later.

But is that even important? The goal was to get resolved. Ved, so to find a way to get forward. The principles are still very useful .

principles for some reason, I don't know why, but this model of baLance coupling is way easier for people to grasp and to start using them.

I'm getting that yeah, i'm getting that four levels. That's all you need to know yeah just .

that conversation of sorting your problems into these different categories and then saying and then you have an approach strategy for .

each one that's different yeah and if you look into pretty much almost all parents from the my german design, they have that balancing behind the scenes. If you have, for example, eric kelvin always says that not all of large system is going to be well designed. He means that supporting substrate ins are not that important.

It's okay around some course. What about sporting abdominals? 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 substance. So again, we're getting that baLance. We can introduce some complexity because we have lower volatility.

But when we are talking about high volatility, of course, sub domains, then yeah, we should keep things as well, design as possible. Sure, we have those patterns, foreign capsule ating models in bounded context. And you're .

also learning to pick your fights right, like you get people to get out to be architecture. absolutely. And everything has to be built the same way where by going through this coupling practice of figuring out what's actually going to be problematic, only fight for the ones they're going to have the biggest harm if they're 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 is is really gonna. What are the consequences of separating IT like you it's worth spending time on that.

Just you don't have do for everything yeah volatility, the dimension of changes or the dimension of time helps a lot here. And because once you spot the high volatility, but where how do you evaluate volatility? And different ways, different models? I prefer to my german design sub domains. And but once you sport a high volatility, then yeah you have a low hanging fruit.

things that first yeah, well, IT also speaks to when we're going to assign a new piece of this APP and we see high volatility. Now I actually have a new opinion about where should IT resign based on where what the coupling looks like, at least initially, I think we should start this in this team where it's close to all the pieces is going to touch. You know, if that changes, we can revise that for the moment, especially when, say, the design is a mature is a new area. Minimizing distance takes a lot of risk of the table.

yeah. Well, let's balus here. Not it's not always possible.

Sometimes when you minimize the distance, you are introducing accident a complexing, right? So I always try for at least logical boundaries within that monthly 是 then we have the distance。 It's going to be significantly lower compared to the initial distribute model th, of course. But still we can talk about different distances within that cold base within that model before we can add the same module, the same logical boundary, the distance is lower compared to different logical bounders within IT. Yeah.

appreciate that.

That's good. So is there anything else that we want .

to cover before we say you out and out? There is more to IT. There is there are degrees for IT for the three levels of integration strengths, right?

That's the one you said would would take another hour .

to explain here they provide more detail and they also kind of help you to identify those specific cases where its functioning.

Coupling with model coupling, right? Well, a lad, hun, enough. His new book is balancing coupling and software design.

Go check IT out. It's fascinating subject, and we've already had our eyes open. And thank you glad for talking .

to us today. And we'll .

talk to you, dear listener, next time on .

dot .

net rocks.

Dn rox has brought you by Franklin's net and produced by pop studios, a full service audio, video and post production facility located physically in new london. Connect cut and of course, in the clown online A P W O P dot com.

Visit our website, A D O T N T R O C K S dot, come for rss feed downloads, mobile apps, comments and access to the full archives going back to show number one recorded in september two thousand two, and make sure you check out our sponsors. They keep us in business. Now, go right, some code, C, N, X, time.

best summer.

你 真是 乱。

In is ryan here, and I have a question for you. What do you do when you win? Like are you a fish pumper car, a high five?

If you a home on those winning moves, check out MBA caso two hundreds of social caso style games for your chance to redeem serious cash prizes. There are new game releases weekly, plus free daily bonuses. So don't wait, start having in the most fun ever at champ a casino.

Black friday is coming. And for the adults in your life who love the coolest toys, well, there is something for them this year too. Martin is the premier craft cocktail maker that automatically makes more than sixty seasonal and classic cocktails each on the thirty seconds at the push of a button.

And right now, but teaching is having a huge cycle de sale. You can get one hundred dollars or any cocktail c or cockles when you spend four dollars more. If cocktail lover in your life has been good this year, all the right kind of bad. Get them about t at the push of a button, make bad quality Cosmos mart, manhattan s and more all in just thirty second, all for one hundred of amazing toys, aren't just for kids. Get a hundred of a cocktail maker when you spend four hundred to cyber monday visit about teaching dot com flash cocktail, that B A R T E S I A N dot com flash cocktail.