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.
And any other pleasures you want. But you know, don't get crazy.
No, I'm gonna limit it to dot net Okay, maybe geek up pleasure, maybe a little science.
Yeah, I'm writing my indie year geek outs. Man, it's a pile of work, but I am working on them.
That's great. I can't wait to can't wait to hear them.
Yeah.
All right, Well let's get started with a little thing we call better no a framework.
Awesome. All right.
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.
So this is just a play on x unit, but x unit depends on reflection, and here they're using analyzers.
Yes, some sort.
Of modernized cunts. It's sort of modernized. Yeah, that's good idea. I like that.
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.
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?
Right.
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.
Absolutely or some fish and chips and a stout more.
Like, and it's stout and some mushy peas for sure.
Yeah, you can keep this.
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.
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.
And I'm rich Campbell at masadon dot social.
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.
Oh wow, yeah, what happened in nineteen twenty three.
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.
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.
March first, Eskom, the largest electricity producer in Africa, is established in South Africa. March third, the first issue of Time magazine is published.
Wow, that's cool.
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.
Oh my wow, those are big hailstones that they're killing people.
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.
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.
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.
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.
Yeah, I don't know why you brought that up. Is there some sort of current event or something that you're referring to.
I'm not referring to anything, not referring to a thing. I don't know what you're talking about.
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.
Thank you so much. It's such an honor been here.
Oh you've heard of our show?
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.
Yeah, we get that a lot.
We've always taken the engineering side of the show very seriously. Yeah, the content we have more fun, but quality audio is important.
Our content quality went way up when Richard joined the team, that's for sure.
That's a long time ago. Man, it's coming up on twenty years, like in a few months.
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.
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.
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.
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.
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.
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.
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.
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.
Have a service that returns the current versions of all the services that you should be running.
That wasn't a problem at all. We were fine, Everything was fine. That's fine.
If you had a merge conflict in that service, the version service service service version service, oh my god, nightmare.
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.
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.
Sure. On the other hand, in the same language.
Yeah.
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.
Right.
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.
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.
Effect ask a question, get an answer.
Yeah, And the opposite of that is going to be high. I'm out of an aggression strength high amount of knowledge over.
Small distance right now local.
Yeah.
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.
Yeah, maybe they're both injecting the same services, that kind of thing.
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.
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.
Yeah.
Yeah, but that's so.
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.
Knowledge, Yeah exactly, Yeah, and that makes sense. The next question is how do you evaluate that knowledge?
Right?
Yeah, And that's the complicated part, because how do you measure knowledge? Like what is the management measurement unit for knowledge? Yeah?
But how much do I need to know?
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.
Yeah, it.
Memories make the batman stop.
Yeah. So what I'm doing here is I'm introducing a dependency on your implementation detail.
Right, and I can break you very easily by modifying my database for my next version.
Exactly.
I not know that I did exactly. Yeah.
That's why let's call this level intrusive coupling. I am intruding your boundaries.
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.
It depends what I'm doing there.
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.
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.
Yeah, but this seems like I don't do this, this is bad.
Yeah, this is only.
Level one depends let's get back to it.
Okay, let's get back to it.
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.
Change, so they resonate together.
Yeah.
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.
But is it one of the arguments that you should have been the same service.
Yes, but let's get back to it later.
Okay, I'm jumping head.
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 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.
But models don't change as often as functionality does.
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.
This is that public API inter face mindset exactly.
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.
Yeah, at least get people in the categories, right, yeah.
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.
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.
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.
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.
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.
Right.
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.
Simultaneously, functionally, but coupled.
Yeah.
Once we were introducing that asynchronous communication between them, we are kind of extending the distance, right.
Yeah.
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?
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.
I would ask, why did you choose this model? Oh, why do you need that?
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.
You're not going to get any changes.
Got to go directly to the database, that's what you're saying.
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.
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.
Yeah, balancing coupling.
Yeah, balancing coupling or dec degree.
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.
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.
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.
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?
Why? Yeah? Why are in the same team?
Yeah?
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.
Yeah.
Absolutely, I think.
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.
First we fix the architecture, then we fix the team architecture.
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.
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.
Yeah, it's easier to change code than people.
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.
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.
I find depends on the person. But also like you can work into more independent you don't need to be here.
Yeah, there's another team we want you to be on because it'd be more effective there, and that kind of thing.
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.
Interesting.
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.
Cool.
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.
Big lie totally turned out. People use the software and it ruins everything.
I know, if you just get rid of the people, chopped so much.
Yeah, you know, as long as nobody uses software, it works great.
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.
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.
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.
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.
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.
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.
Interesting. Yeah, that doesn't seem like the right path, but I can see why it would be right.
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.
If you need to. Productivity goes up. Yeah.
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.
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.
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.
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?
So usually when they call me, these people have already left the company. Ah really, well, maybe they were promoted so that they.
Yeah, Gilbert Principle failing upward and moved to management.
There you go.
Yeah, I see, but you you have obviously at some point experienced and pushback, right of course. Yeah.
But at the same time, they're not calling you because things are going well.
Yeah.
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.
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.
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.
Driven because it makes your foot look big and it's a it's a pistol, you know.
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.
Yeah, yeah, yeah, Bob's pattern.
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.
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.
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 it approach strategy for each one. It's different.
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.
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.
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.
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.
Yeah.
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.
Yeah, I appreciate that. That's good.
Yeah, So is there anything else that you want to cover before we say goodbye? Any shout outs or anything shut outs?
Not surely. I just want to remind again that there is more to it. There are degrees for the three levels of integration strength.
Right, that's the one you said would take another hour to explain.
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.
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.
Visit our website at d O T N E t R O c k S dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September.
Two thousand and two. And make sure you check out our sponsors. They keep us in business. Now, go write some code. See you next time.
You got your middle.
Vands do the same. This is hard than my Texas