Loosely Coupled - Deep dive into coupling with Domain-Driven Design

Good morning, good afternoon, and good evening.

Welcome to another episode of Loosely Coupled by Bridging the Gap.

My name is Karol Skrzymowski, I'll be your host tonight, and today's episode is sponsored by the common cold.

So I have some nice citrus and ginger and some other herbs brewed in the pot for myself just to get through today.

And today, well, we are having a topic that is actually very much related to the name of the stream, so we're going to talk about coupling, and in context of domain-driven design, which I think is, for our guest, is one of the few occasions when he can talk about coupling and domain-driven design at the same time, because I've seen quite a few trainings that he restrained himself very, very much.

So, without further ado, welcome to the stream.

Good evening, Vlad Khononov.

Hey, Karol, thank you so much for having me.

Hello, hello.

Amazing that you could join us, and we can talk about domain-driven design and coupling at the same time for a change, right?

Yeah, yeah.

Two topics I cannot shut up about, so I don't know how long this stream is going to be.

I mean, I just been through, what was that, a month ago, through your training at O'Reilly about balancing coupling and software design.

You really, really had to restrain yourself.

I saw that in you.

You were like, oh, I'm not supposed to talk about domain-driven design, but I'm going to mention domain-driven design.

Yeah, that's true.

Speaking about that training, before we jump into the topic, Vlad, please, please, give me an IT dad joke.

Oh, so you want me to embarrass myself from the get-go, right?

Okay.

Let's do this.

They were great.

I laughed my ass off during the training, so please, please enlighten what to do when you're waiting for people to answer and chat during the live training.

I see.

Okay, so why did the programmer quit his job?

Why?

He didn't get a raise.

A raise?

A raise?

Yeah, smart, right?

That's not something I'm proud about.

Fair enough.

That joke's a side.

Coupling and domain-driven design, these are the two main topics that you do, that you are about in literature, in variety trainings, talks with people.

Why those two specifically?

Yeah.

Well, first of all, because I love domain-driven design, learning this methodology for me was truly, not exaggerating, a career-changing experience.

Now, eventually, that led me to coupling because during one of my DDD endeavours, I had like a complete disaster, like cosmic-level disaster of a microservices project, like something that was supposed to be this perfect microservices-based future of everything decoupled and everything that can evolve independently.

And it was like, buy the book, distribute monolith.

And the annoying thing was that I was doing what smart people were telling me to do.

So, whenever, when that project was completed, I said, okay, I have to understand what the hell went wrong.

Like, why this promise of everything uncoupled or decoupled or whatever turned out to be coupling a nightmare.

So, I started researching coupling and yeah, I just couldn't stop.

I was fascinated by this topic because it answers so many questions beyond that microservices failure.

So, which was first, DDD or coupling?

DDD.

DDD.

Okay.

And then, I remember you mentioning to me that it took you about five years to complete balancing coupling and software design, which was published in October 23.

And then in the meantime, you wrote learning domain-driven design, which was published in October 21.

So, it was like parallel, parallelly developed.

Yeah.

So, balancing coupling was published in October, end of September, I think, 24.

Now, I started working on both of them because, let's say, reasons, not because of something I'm proud of.

I did a mistake and I had to start writing two books at the same time in 2019.

Now, learning domain-driven design was smooth sailing for me.

Like, come on.

I did many trainings.

I already had that what is domain-driven design report for O'Reilly.

I just had to extend it.

And, yeah, that book was easy.

Now, the coupling book, it was like a real challenge.

It was either me or the book.

And, of course, the writing balancing coupling and software design was basically during a very problematic geopolitical era where you are at, right?

So, that was also quite a factor.

Oh, there were so many factors.

Like, I don't want to get into it, to be honest, because everything that could go wrong went wrong during those five years.

Like, everything.

We had COVID, by the way, 2020.

The whole world stopped.

I got stuck in a foreign country for four months.

I couldn't get back home.

Yeah.

So many crazy stories.

I can write a whole book about, you know, things going wrong during writing of balancing coupling and software design.

Yeah.

And, yeah, and eventually I missed the deadline.

Come on.

What was the deadline?

So, the deadline, I had it back here on this wall, so now I removed it.

But it was, if I remember correctly, it was October 21.

October 21.

Yeah.

Three years later.

All right.

Just some technical issues that we're facing.

First technical issue.

For some reason, comments from LinkedIn do not show up in our studio.

So, I hope the comments from YouTube will.

Something went wrong technically and we don't have that integration handled for some reason.

Technology, right?

And then the second public service announcement, because Vlad is currently experiencing a storm outside, and power tends to give out.

So, if Vlad suddenly disappears from the stream, he'll be back in a few minutes, and then I'll be forced to say dad jokes in the meantime.

So, for all of you to be warned that if Vlad just disappears, he'll come back.

He'll come back.

But it may take a minute to do so.

I'll be monitoring LinkedIn on one of my screens, just a feed of comments anyways, just to put those questions in as we go.

But unfortunately, for some reason, technology fails at times.

That's what it is.

So, as a real software engineer, you miss deadlines, you failed at a project, you decided to learn from your failures, and that's why we have learning domain-driven design, and that's why we have balancing coupling in software design as the two books.

Both really great books, because I read both of them and enjoyed every second reading them, and they were quite influential.

Especially for me, not knowing domain-driven design, I was way easier to digest than the blue book by Eric Evans.

So, that was a big influence on my education, at least.

I hope that others as well.

I know quite a few people that read learning domain-driven design, and they really enjoyed it.

So, now we can talk about domain-driven design in the context of coupling.

Now, the question is, where do we begin?

Whenever.

Just pick a point, and we'll make our way through.

Okay.

Since I'm an integration architect, let's limit ourselves to system-to-system integration for the moment.

Maybe we'll dive deeper into nuances, but let's start there.

A lot of architects think that integration is simply exposing rest endpoint.

Now, if we integrate a system to a system, so let's assume we have a SaaS solution.

It exposes an array of APIs, and we call that API from another system to do something, whatever that may be.

At this point already, what kind of coupling we can expect and should consider as architects?

Yeah, so, at this point, we don't have all the answers, obviously, but we have some questions to ask.

So, first of all, that API is our integration contract, something that we're using for integration.

That's what we know about that upstream system.

That's how we are integrating so we know what is the integration contract.

The question is, what is reflected by that integration contract?

If that integration contract is based on the model of that business domain that is being used internally in that upstream system, and that model is exposed through the API by using the same semantic terms, then what's going to happen if they need to evolve the model?

Well, it's going to affect the API.

In that case, we have a breaking change.

Yeah.

So, now we have in that case, we'll have not contract coupling, but model coupling, because we have the knowledge of that model.

Now, what if in order to work with that API, I have to know something about how it functions internally?

Maybe there is some functionality that I have to duplicate in my system as well, because otherwise that integration won't work.

So, now we have two functionalities being implemented in that upstream system and me, the consumer, the downstream system.

Well, in that case, that functionality has to be changed simultaneously while we have a much higher level of knowledge that is being shared.

Now we have functional knowledge.

And ultimately, what if that system wasn't intended to be used through that API?

Maybe that's an internal API, and you just figured out that, hey, I have that system by other team.

They probably never intended other teams to integrate it with it, but I'll do it anyway.

In that case, we're intruding their encapsulation boundaries.

We're integrating with something that we shouldn't.

So, that's going to be intrusive coupling, including the encapsulation boundaries.

So, these four examples are four kinds of knowledge that can be shared across component boundaries whenever we have coupling.

Like contract coupling is the lowest, all the way to intrusive, which is like the highest.

And the more knowledge we are sharing, the higher the likelihood that when there is a change in the upstream, it will require a corresponding change in the downstream as well.

So, we'll have cascading changes.

We'll have a system that is a distributed monolith.

Like my project.

My first microservices endeavour.

Fair enough.

All right.

I've been taking notes, but apparently my keyboard is louder than you speak, so I'm going to stop noting on my, well, clank keyboard.

Okay.

So, contract coupling would be the lowest, then, right?

So, contract coupling means that we define a contract.

We define a data model for exchange of information.

And from a perspective of the one providing an API, that would be some sort of a, in the best case scenario, that would be some sort of a open host service in DDD nomenclature, where we have a published language, which published language is the specific definition of an object that we're exchanging or a service that we're invoking, whatever that may be, right?

Yeah, yeah, exactly.

That's the beauty of domain driven design.

It has answers for all the questions.

It just takes time to get familiar with all that terminology.

So, yeah.

Open host service, that means that we have a bounded context, like service system, that exposes an integration contract that is like a model of a model.

It's a model of their implementation model, which means the implementation model can change without necessarily causing corresponding changes in the integration contract.

And it also allows us to use multiple integration contracts, or in DDD terms, multiple published languages.

So, we can expose two versions of the API that will work with the same implementation model underneath.

So, yeah.

That's contract coupling in domain driven design.

And this, what we talked about in terms of domain driven design, that's the general term for these phrases is context mapping, just to put it in perspective.

Yeah.

So, in strategic domain driven design, we're dealing with coarse grain design decisions.

We're identifying business subdomains, identifying their types, so that we'll be able to make smarter design decisions later on.

And we also design coarse grain components of our system.

They can be microservices, but they don't have to be microservices.

Bounded contexts can be wide.

Call them modular monoliths.

It doesn't matter.

Now, once you have those bounded contexts, they cannot be independent.

If they will be fully independent, they won't work together, that's not going to be a system.

They have to work together.

Now, how are we going to integrate them?

That's not a trivial question.

And to answer that question, domain driven design provides us with that notion of context mapping.

Like, how do we map the integration of different contexts?

And there is a number of patterns that fit different situations.

Some patterns are for cases when we have, let's say, well-established collaboration between teams in terms of those bounded contexts, and others when, you know, we have some organisational friction between the teams, and we have to address that in our software design.

So, that's overall called context mapping in DDD.

For those who want a quick cheat on context mapping, there's a very nice repository on GitHub from DDD crew, and you can have, there's a very nice large picture with a cheat sheet of all those different types of context mapping patterns that we're talking about right now.

So, feel free to scan the code and grab it, or just Google DDD crew context mapping right now, just to have that context for yourself.

All right.

Now, if we're looking further, so we had contracts, we have open host service, that's the best case scenario, pretty much, that we can have.

So, the lowest form of contract that we can have here.

And then, if we go down into the model.

So, if I recall my good old days when I was still working with XML, XSDs, and WSDL files, of course, now you can do the same in open API specification.

We use namespaces, a lot of them.

So, if I wanted to have the API definition separated from the actual model that it was underneath, at least the data model, because that data model only composes the part of the model, right?

Then I use two different namespaces, and I could completely separate them, and the internal data model could be different, could be bigger than the one that was exposed.

Now, a sin that I did back in the day as a, I believe, junior developer still, when I was still working on integrations very actively, one time I exposed the internal namespace in the API.

And then, let's talk about what happens then.

What are the consequences of such a exposition?

Because then we jump into the model coupling, literally, right?

So, what are the consequences of this?

So, first of all, you're saying you did it by mistake, which naturally puts you in a great position, because I know many people making that on purpose.

True.

Now, I was very much aware that this was a mistake, and I managed to fix it four years later, but that's how long it took to fix it.

I see.

To find the budget and to actually touch that part of the integration to make it happen, that required a lot of planning with other systems to actually refactor this.

Yeah.

So, here, domain-driven design, first of all, domain-driven design says that once you're exposing your model with distant teams, distant consumers of your API, whenever you will want to change that model, well, you will have to negotiate that change with them, because they have that knowledge.

They do know what your model looks like, and now you want to change it.

So, in order for them to understand the newer version, you have to coordinate that with the second team.

That's why domain-driven design puts emphasis on protecting that knowledge within bounded context.

We have open host service, we have anti-corruption layer, which is similar but from the other way around.

Now, at the same time, and that's the beauty of domain-driven design, this methodology says, but you don't have to be way too strict about that, because there are cases where you can round corners, and that's fine.

For example, let's say that you're implementing like core functionality of the business, something that is the company's core competitive advantage.

That functionality is the reason why your customers are choosing your solution and not your competitors.

Well, in that case, your business will want to optimise that solution to make it better all the time.

Why?

Because those annoying competitors, they will try to copy whatever you're doing, and you want to stay ahead, so you will have to change frequently.

So, that model, you want to be able to evolve it as efficiently as possible.

On the other hand, there are different business functionalities, which are not truly that interesting from the competitiveness standpoint.

In DDD lingo, they're called supporting, supporting subdomains.

This is the stuff that is boring.

And every system has those functionalities.

You just have to implement, because you don't have any other choice.

If there would be an open source on GitHub, you would love to take it and put it in there.

But there is no such solution, so you have to, you know, five years ago, I would say, you probably could just outsource that.

Today, well, cloud, here's what we need.

And that would work perfectly.

Why?

Because usually, these boring functionalities are also simple.

There is no complexity in the business requirements here.

So, cloud, do the job.

Let's deploy.

Now.

And on top of being simple, they're quite repetitive most of the time.

So, basically, if they're repetitive, then all the lovely LLMs have plenty of source material to learn it.

Because they cannot learn core domain functionalities, because that's our business differentiator.

So, it's not going to be the same.

Right?

And in supporting generic domains, that's plenty of that.

Yeah.

Supporting subdomains, there are usually data entry screens, like those tables that you have to populate, or upload materials, or ETL jobs, like take data from here, do some little manipulation, put it there.

That's it.

Not like a real business algorithm with some business complexity.

Now, why is it important in the context of the question you asked previously?

Well, this thing, nobody cares about it.

It's not going to change frequently.

So, if you expose that model, that's fine.

You are not going to suffer that much compared to the core business functionality.

Now, the important thing, however, is to draw the line, to identify the two cases.

Because again, I've seen companies running that corner, exploiting the models, and that works fine.

Nobody complains about it, because those are subdomains.

So, hey, that works for supporting subdomains.

Let's do it for our core business functionality.

And guess what?

Nope.

Nope.

Yes.

Let me guess.

The word would be volatility.

Yes.

The volatility, the rate of changes in core subdomain is way higher than supporting subdomain.

Talking about subdomains, where would you place an integration platform?

An integration platform?

Yes.

So, ah, okay.

That's my favourite answer.

Go on.

No, that's it.

That's the answer.

It depends what kind of integration that is.

Because there are integrations that are simple.

Like, there's nothing really interesting about it.

Like, in terms, you at most implement anti-corruption layer.

You take the model that is exposed by the upstream, do some modification on top of it, and here you have your data.

That's it.

So, that would be like supporting flavour.

But I've also seen companies that didn't have any core subdomain, like, in its regular sense.

Like, there is no business algorithms, nothing really interesting.

However, the integration magic they did about things that looked unintegratable, that was their competitive advantage.

So, in those companies, the integration was their core subdomain.

Oh, interesting.

Because I always consider integration platforms and integration as a field being mostly the supporting subdomain.

The technology itself is generic, but what we do with that technology as a platform technology and how we build those integrations usually lands in my book in supporting.

That's what I see most of the times.

But that's an interesting view on it.

I will give you an example.

All right.

So, let's say you're implementing a system that is going to send receipts that you get in a shop as an SMS message.

So, basically, that system does integration of that cashier's computer or cashier's printer and whatever system you're using for sending SMS messages.

Is it trivial?

Hell no.

That's by far not a trivial system.

That's, like, complexity on top of complexity.

But in the heart of it, that's integration.

Okay.

That makes a lot of sense.

Going back for a moment to AI, we have a nice question from David, or a colleague from SAP.

Hello, David from Palo Alto.

It's nice that you could join us.

So, to what degree we can teach AI agents about DDD and coupling?

Yeah.

Hello, David.

Yeah.

That's a great question.

And the thing is, we shouldn't, at least now, trust whatever those models know about domain driven design and coupling.

Because that's, like, an average answer on Stack Overflow.

That's the level of knowledge.

Not the best answer on Stack Overflow, the average one.

Which is kind of, on Stack Overflow, you can see people saying domain driven design is about buying effective domain names.

Now, I'll tell you what works best for me.

And like with people, teaching the theory, but showing examples.

Like, here is what I mean by an aggregate.

And sorry, I'm going towards lower levels of abstraction.

But I have to now.

Yeah.

So, an aggregate.

If you ask it to implement an aggregate, it will do something.

Is it going to be like a proper domain driven design aggregate?

Who knows.

So, give it examples.

And that works.

Coupling, same story.

A friend of mine, Gregor, showed me as a repository with cloud skills.

And one of them is about evaluating modularity.

And for that, he uses the balanced coupling model.

So, he teaches the model to reason in terms of balanced coupling.

He says that what works for him is first iteration, first implementation of a codebase, do something that works.

And then use my skills to evaluate the problems in the design and improve it over time.

So, after, like, three or four iterations of improvement of refactoring, he says that the codebase looks almost as if he wrote it.

So, yeah.

I would say, David, yeah, you can teach them.

So, basically, fine tuning or context engineering with giving examples, as David here comments further on the matter.

When I use gen AI for a number of things, that usually is the approach to engineer the context and then provide examples, what I mean by specific terms.

And that really speeds up work at times.

Not always.

Because, like you said, average answer.

Not the best answer, but the average Stack Overflow answer.

And in terms of the field of integration architecture, that's the average answer is way below the norm I would consider average, because AI just didn't have materials to learn from.

And that's a completely different problem in that space.

All right.

Going back to our REST API that we started with.

So, okay.

We had model coupling.

So, we exposed the exact same model.

So, we create that brittleness that every time we change the model, we impact our consumers.

Which is a problem on its own.

Now, with an example of a functional coupling.

And in my head, when I listen to you explaining functional coupling, I instantly it's popped into my head a API where there were optional elements.

But because the structure of the API is very poorly designed, for example, it's a flat structure with optional elements.

But there are dependencies between different elements that some elements need to exist, coexist with one another when you call, even though they're optional.

And it's nowhere described.

So, would that constitute the level of knowledge about the system and the implementation of said API to be already functional coupling?

That I need to know how that system behaves underneath and what data does it really expect to work?

Otherwise, it will return me an error that it's missing an element, even though all the elements were optional.

Well, that's an interesting question.

That's an interesting question.

So, if you have an API that is not explicit, what you're describing is a very implicit API.

True.

Now...

Many of these I've seen.

Yeah.

What I like to use for evaluating the complexity of or implicitness or explicitness of a contract, integration contract, or a model coupling is the static model.

So, Kinesans is a scale of evaluating components in object-orientated code.

That was the main goal at the time that model was introduced in the 90s.

And it has a number of levels, and all of them basically describe, okay, we have two components, one depends on the other, what the downstream needs to know about the upstream.

Does it have to know just the name, let's say, of a method or parameter?

Does it have to know the type?

If, let's say, a number has like magic value attached to it, like you pass seven, and that seven means not number seven, but order of status completed.

So, specific meaning.

That is also part of that model.

And the next level is, it has a very misleading name.

It's called Kinesis of algorithm.

And this one is actually about those quirks that you have with implicit interfaces.

And it kind of reminds me of that one, I would say.

And that puts us either in integration contract, contract coupling, or model coupling, not functional coupling.

So, functional coupling, it's not about functional coupling, it's not about the data structures.

It's about the behaviour of a system, something, the behaviour that it implements, and the knowledge about that is being shared with a downstream consumer.

Now, when we're talking about this level of abstraction, luckily, luckily, examples of this level of coupling are not that common.

But, we still have them.

So, I just pulled this out of O'Reilly straight from your book.

So, these are the levels of coupling, and then the Kinesis of name, type, meaning, algorithm, and position.

So, where algorithm is here in the contract coupling, then if we're talking about functional coupling, then it's a different set of Kinesis.

Yeah, but pay attention that static Kinesis, it's used for degrees of contract coupling, but also of model coupling.

So, it's all about the intent.

Kinesis on its own, it communicates, okay, what type of, from the technical perspective, what do I need to know?

Now, with that differentiation between contract and model coupling, we're saying not only technically, but business-wise, what that term or what that piece of knowledge means.

Does it belong to an integration model or the implementation model?

Right, and this is why in contract coupling, we also have the Kinesis of meaning, because I think it's worthwhile to mention that, first of all, coupling is a spectrum, as we see here on the shown diagram, but also it's not that all coupling is bad.

There are types of coupling that are actually very much wanted, like contract coupling and the Kinesis of meaning in that contract coupling, because without it, we wouldn't be able to do any business over APIs.

Yeah, actually, I would even argue that there is no bad level of integration strength.

So, this model, I call it integration strength.

It describes different levels of knowledge.

Now, even when we're looking at that big one on the right-hand side, intrusive coupling, we can still find examples of scenarios in which that is going to be the effective design.

So, I wouldn't, well, I hear people label like this is, this level of Kinesis is the bad one, you have to avoid it.

Yeah, it may be wanted or unwanted, but then it depends on the context we're in, right, because sometimes it will be very much wanted.

In my world, when I do application integration between various domain systems, I usually want to limit myself to contract coupling.

But this is on a very large distance, and I don't want to share that knowledge over large distances.

But if I would be doing, I don't know, a small application over my Google workspace, because I automate the hell out of my Google workspace, then intrusive coupling is perfectly fine in that case, from my perspective.

Yeah.

So, as you said, it depends on the distance, the physical distance between coupled components.

If it's a big one, yes, like in your example of systems, you want to minimise the shared knowledge.

Unless, as we mentioned previously, the upstream, the source of knowledge, is not going to be volatile.

It is not going to change.

In that case, if that will free up time and effort that you can invest in core business, invest it there.

Just the simplest thing here, where volatility is low.

Now, I still have it on my stack, your question about functional coupling.

Let's get back to it.

Yeah.

So, let's imagine you have, you're exposing an API.

And that API receives some field.

And that field has some non-trivial validation rule.

Maybe it's, you know what?

Email.

Like, simple email.

So, we have an email that should be passed.

However, internally, only Google email addresses are supported.

So, maybe they're ending with Gmail, or maybe it's Google for domains.

I don't know.

I encountered that.

So, the API looks like, okay, I can pass any email, but only Gmail works.

Now, whenever that internal implementation will change, if they add support for, I don't know, Microsoft Live emails, that's going to affect the functionality that can be implemented by the consumer.

So, that's kind of borderline example of functional coupling.

Now, we can take it, the same example, in different context, can be even contract coupling.

But the case that I'm basing it on, like, real life case, that was an example of because I'll explain.

The consumer had to support the same platforms implemented by the upstream.

That I actually seen that in practise.

Only the other way around.

It's not about having a specific platform.

It's excluding a specific platform.

Oh, even worse.

Okay.

Even worse.

Because I remember registering for a trial account with one technology.

And to register, and that technology also, when you register to the academy, they offered certifications for free.

Which was very lucrative.

But because they had too many people registering, just to get the certifications for free, and they cheated the hell out of the certifications because they were not proctored, so they decided that they allow registration only with company emails.

So, if you have the popular email, like Gmail, Hotmail, or any other this kind of an extension that is a common extension from a public email service, then you couldn't register.

So, that you fill out the form, you call the API, and the API says, sorry, you cannot register.

So, I think that's an example also of the functional coupling in that sense.

Because then the form actually, the frontend had to implement specific error handling to handle that somebody sent in the data that are not validated.

But they didn't implement any validation on the form itself.

Which was interesting.

Yeah.

Again, examples of functional coupling on that level of abstraction are pretty rare.

But again, they exist.

If we get back to my second favourite topic, domain driven design, then we have, like, a pattern.

Not an entire pattern.

A pattern.

In domain driven design, specifically, that teaches you how to do it.

How to implement functional coupling on that level of abstraction.

And people who are familiar with domain driven design may already figure that out.

That separate waste pattern.

That's the case of you have two bounded contexts that are owned by different teams.

And people in these teams, maybe they hate each other.

Maybe they locate it in different time zones.

Or for any other reason, they cannot collaborate.

So, the idea says, okay, in some cases, don't force them to collaborate.

Instead, just let them duplicate their own functionality.

As long as that functionality doesn't block the core subdomain.

In that case, that's going to be a pain.

If it's generic, if that's supporting, let them do it.

We'll have functional coupling.

And this is where Conway's law comes to play a lot.

So, that we organise our architecture according to the team composition, not the other way around.

That's where a lot of other things come to play where we actually, especially in large corporate environments, when there is a lack of communication between different departments, different lines of services.

And we get shadow ITs.

And then we have those separate ways.

Not only because people hate each other, but because they just don't know that they exist.

And this is a lovely mess.

That's a dangerous mess.

In that case, they can end up duplicating core subdomains.

I don't believe I've ever seen that, but you're absolutely right that this could be a non-trivial risk.

That would be hellish to dismantle.

Now, okay.

If we're looking at functional coupling or even intrusive coupling that is

unwanted, and if we mitigate by having separate ways, or we have that shadow IT,

looking at domain-driven design and looking at coupling problems, especially the invisible

coupling, because there is a kind of coupling that is not visible, especially if we have

two or three teams implementing the same functionalities,

maybe not knowing about each other, then how to even get into that and try to dismantle that?

Especially that this kind of pathological coupling, it's very, very hard to identify.

Yeah.

Yeah.

It is very hard to identify.

And as Eric Evans said years ago, not all of large systems are going to be well-designed.

That's something that we have to just understand, agree, and live with that.

That's a rule of life.

There will be entropy somewhere in the system, but with domain-driven design, what we can do is we can steer that entropy to parts of that system that don't really matter, like supporting subdomains or ex-subdomains.

If we can do it, that's it.

We did our job as designers, as architects, whatever.

So, going back to your question, how do we dismantle it?

I would say that that's my first answer when people ask me about domain-driven design.

How do I introduce it?

We have that system, its legacy, it's been implemented for X amount of years.

And we have turnover of engineers.

What do we do now?

Well, you are not going to tell Cloud to rewrite it and make it perfect.

Like, hey, Cloud, I want this to be domain-driven design.

Go ahead.

Or even Ralph, it's not going to work.

So, instead, what we need to do is to identify pain.

Now, that can sound funny, like pain in the system.

Well, I'm that serious.

And identifying pain is important and it can also be difficult, because in those types of companies, people get used to pain, so they don't feel it anymore.

They're like, okay, yes, so I want to change the colour of a button and it's going to break something in that team.

And yeah, I have to do that first.

I've been doing it for years, yeah, and I'll do it for another year.

So, that's integration pain.

But people are not noticing it.

So, as an external consultant, I believe that our goal is to identify, help them identify those pain points to make them as explicit as possible.

To get an agreement that, hey, you have a problem here.

That's something that makes you less effective.

And once you have that agreement on the problem, well, we can discuss an agreement on a solution, how to change it.

Now, change that depends.

Some people are scared of domain-driven design.

Nothing you can do about it.

People hear domain-driven design, they hear complexity, bound of context, aggregates.

I think a lot of people are scared of the word complexity or the word governance.

And it's like, they hear governance, you start talking about, okay, we need to implement some sort of governance over this.

And they go like, no, no, no, no, no.

We don't need more governance.

And it's not that they don't need governance, they just didn't have good governance over things, they just had the management.

Yeah.

Yeah, so, people have different traumas.

We have to adapt the solution we are proposing not to trigger their traumas, their PTSDs.

And if people are afraid of domain-driven design, well, that's fine.

I can talk to you in terms of coupling.

So, we have here a model that travels long distance and its source is volatile.

What can we do about it?

Can we make the source less volatile?

Yes or no?

No?

Okay.

So, let's shorten the distance.

Or maybe we can reduce the knowledge.

If not, shorten the distance.

That's the coupling terminology.

I love it because of its effectiveness.

Now, domain-driven design, if they're not afraid of it, okay, let's talk about models.

Like, what's going on?

Why do we have those, maybe, cascading changes?

Maybe we have coordination issues.

Maybe we have constant friction between teams.

All those issues can be addressed by picking the right DDD pattern.

And again, you don't have to refactor the whole thing.

Just identify strategic areas that really, really beg for improvement.

Prove them.

Like, do the 20% of work that will bring you 80% of the value.

But for that, you need to really identify them and model them out, right?

So, which of the tools available would you use to identify, to do that discovery?

Yeah.

So, there is one tool and it's the hardest, at least for me, because I'm an introvert and that's talking to people.

Like, having those conversations, like really understanding what annoys you, what makes you less effective, what are the frictions.

And sometimes people are afraid to tell you because politics.

They don't want to sound like the one who complains about everything.

So, yeah.

I try to figure it out.

Exactly.

Yeah.

And then Philip continues.

If you're here for the first time, you have to model.

Fight for the win.

Yeah, but Philip is my co-author of the DDD training and he's very versed in DDD and he's a DDD coach.

So, he can be a smarty pants about it in comments because he went through all those dramas related to domain discovery, et cetera, going into event storming and using those tools on a lot of conversations.

And you're right.

This is, yeah, for an introvert, that's definitely something that may be problematic.

And I'm not the one to enjoy these conversations always myself.

I do instigate them often, but sometimes they can be very, very difficult.

That's very true.

Because literally when we were doing that domain discovery, we're touching the really painful parts.

That's what I see at least.

And speaking about the painful parts, can you tell us a little bit about the sociotechnical and social organisational aspects of coupling?

Because I think these are the parts of coupling that very few people talk about.

And I know that you have plenty of stories on that to explain that and tell us how this actually works because they are also, in my opinion, very relevant, not only for interoperability topics of integration architecture, but for running a company and actually using domain systems to run the company and do business.

Yeah.

Yeah.

That's a great question.

It takes us back to the notion of distance.

Okay.

So we have knowledge that travels from component A from the upstream to component B, the downstream.

Now, what is the distance that is being travelled by that knowledge?

If they are close to each other, maybe within the same module, maybe even within the same file, the distance is low.

If you have to change them simultaneously, that's going to be easy.

Like they're close to each other.

It's almost like modifying one thing.

On the other hand, we have, let's say, the other extreme that you mentioned.

We have two systems or maybe two services in an enterprise company.

Now, those two services are different code bases, different projects, different repositories probably.

And if they have to change simultaneously, then, well, now you have some effort that you need to invest to make the change happen, because you have to coordinate that change across that distance, across those components.

And of course, that also induces cognitive load.

It makes it easy to forget that there is that distant part of the system that has to change as well.

So you will just change what you remember of, deploy it, and see the fireworks when you deploy to production.

Now, that's the technical aspect of it.

And as with everything in our job, things become more complicated because of people.

Now, let's introduce people into that equation.

So we have, let's say, two bounded contexts, being integrated, sharing knowledge, sharing lots of knowledge, and they have to co-evolve.

For reasons.

Let's say that they are sharing knowledge of model.

Kind of no-no in DDD world, but let's say that that's our scenario.

We have two bounded contexts, model coupled to each other.

The model changes one, the second one has to implement the corresponding change as well.

Guess what?

Although that sounds like a no-no in domain driven design, in domain driven design, that's actually an integration pattern, part of context mapping.

That's called partnership.

In partnership, two teams implement ad hoc integration.

They just integrate somehow.

Whenever that integration doesn't work, they will resolve that integration issue through collaboration, through conversations, through helping each other.

Now, when that pattern is not going to work?

Well, when those two teams don't have that well-established collaboration.

In that case, that pattern is not going to work.

Now, let's talk, what is the difference between the two scenarios?

Well, first one, those two bounded contexts could be implemented by one team.

Can they collaborate with themselves?

Probably, yeah.

So, in that case, the distance is kind of, let's say the distance between the people is short.

So, we have the technical distance plus the personal, interpersonal distance.

That one is short.

Maybe these are two teams sitting in the same room because that's a small startup company, they're maybe working out of the garage, and they really try to help each other because that's their only chance to collaborate.

That pattern will work.

Again, the social distance is low.

And maybe they succeeded, and that company has grown into an enterprise.

And now, those two bounded contexts, same bounded context, belong to two teams that are maybe they're in different geographical locations.

Maybe they're in the same building, but they just have different goals, and they don't want to collaborate.

Well, in that case, domain-driven design says, hey, you have a problem, partnership won't work in that case.

You have to use a different kind of relationship, either open host service or anti-corruption layer, or in the worst case, separate ways.

Now, what does it mean in the language of coupling?

Well, if we have well-established collaboration, model coupling can work.

If people are not willing to collaborate, then we have to reduce the knowledge.

The distance is bigger, we have to reduce the knowledge.

We have to go to contract coupling, open host service, anti-corruption layer in domain-driven design terminology.

Yeah.

So basically, you're saying if we can maintain a very short social distance that we can manage tight coupling.

But if the social distance is high, we will not be able to effectively manage that kind of tight coupling between two different systems, modules, or whatever we have coupled.

Look, again, you know the answer.

It depends.

So I've been in a situation in which a team of three people implemented a huge, huge, like not monolith, like a huge big wall of mud.

They were close to each other, but the technical distance was already way too big, so it induced too much cognitive load, and that close social distance didn't help.

Like, if you have infinity and you increase it by zero, well, guess what?

You still have infinity.

So it didn't help.

Now, in my previous example, what I meant is you can make some pragmatic decisions to round some corners.

So bounded contexts, you probably don't want to share functional knowledge.

You can share model knowledge to a degree.

Like sharing integration contract, that is a perfect case.

Startup companies, guess what?

Not always you have time.

Sometimes you have to be pragmatic.

So in those cases, what I'm saying is if the social distance is managed, then yeah, it can work if you're around the corner.

But you have to watch for organisational changes, because organisation grows, change, yeah, and it's going to make your design decisions that yesterday a disaster tomorrow.

I've been in a company once that was acting like a startup, and they assumed that the social distances were very low, and they required tactical decisions all the time.

Speaking about architecture and proper patterns in engineering was frowned upon.

And of course, they suffered through that horrendously, because they had so many tight dependencies between different teams that at a point, they couldn't even manage that.

So that heavily influenced the code base of all the teams that work in a completely separate modules and completely different things functionally.

And just to weigh in here, we have the user with a lovely name left toe, getting lost in our conversation, because we're flowing towards people management, I think it's worthwhile just to reiterate that software as it is, it's not just an art form that we just sit down and write software, that software usually has a purpose.

And that is a business purpose.

And it comes from people.

If people don't align on the purpose of the software and on the requirements on the dependencies, then we're going to have a problem that influences our architecture, and development and testing and the actual end result and usability of that software.

And even if at first it is usable, then because we have those dependencies that different types of coupling, then we'll have a problem later, because it's not going to be scalable, it's not going to be extensible, or whatever other characteristic we're diving into.

And I see the YouTube comments were started to go crazy to the extent that I'm not able to keep track because they started talking about the trolley problem and railroads all of a sudden.

So, aligning teams as a railroad, and everybody has their own tracks.

So, YouTube is going crazy tonight.

That's absolutely cool.

So, we could have a laugh.

Instead of dad jokes, we have YouTube comments going in to have a laugh about.

Great comments, by the way.

Yeah, that's a cool way to model it.

And they're basically on point of the discussion.

Absolutely.

And especially this one.

People management and organisational management and making organisational changes is an integral part of design.

Without stakeholder management, we can't really do proper design, because if we don't identify those key stakeholders that we depend on for the success, we're probably going to fail.

But that's, again, a different part of it that is not exactly coupling coupling, but this part of DDD where you need to bring the right stakeholders, the right people with knowledge into the room to model out the behaviour, model out the business process, model out the bounded context domain and the dependencies between them.

I can take it towards coupling.

No problem at all.

Please do.

So, what domain driven design tells us?

It says at the core of strategic domain driven design, we have to cultivate ubiquitous language.

We have to build a shared understanding with domain experts, and we should do it by that annoying way of speaking with them and building that shared language in the language that business people understand.

Now, in DDD, that's called ubiquitous language.

So, ubiquitous language basically reflects their mental model.

So, we're using the same model of the business domain to communicate with them.

Now, if we're not going to do it, if, on the other hand, we'll try to build one canonical model of the business that's going to address all use cases of the system, no matter what business stakeholder it addresses, well, guess what?

When you will communicate with that domain expert, you will have to use different models, models that are not related to that stakeholder's perspective.

So, that knowledge will flow in that conversation.

And given that we all have a slightly different model of reality anyways, because we all model whether we want it or not, it's always a matter of aligning those models.

And without talking about those models, we will definitely have different models in our heads.

One of the exercises I always do with people at the beginning is, okay, but what do you mean by this term?

Please explain, because it may be a common term, but maybe also commonly misunderstood.

And then I have an assumption that this is this and this, and my assumption may be wrong, but I'm making those assumptions because I have already a model in my head.

And that's, oh, what is integration?

That's my favourite.

I've been in the company where the word integration meant at the same time, application integration and data integration.

Imagine the confusion, because these are completely two different things.

People absolutely did not know what they were talking about.

And there were literally some people that thought that data integration and application integration is one and the same.

Yeah, that's the beauty of domain-driven design.

Like, come on, talking to people, that's common sense.

Speaking with people in their language, that's common sense.

And that's like the main critique I hear about domain-driven design.

That's just common sense with pencil labels on top of it.

And I'm like, oh, really?

So why the majority of people are not using that common sense?

Why is that common sense not that common?

Why are you not doing it?

Yeah, and again, the joke I make on trainings myself, if you put four architects in the room, you'll have five different opinions, exactly like Toasty here says about six explanations from five different people.

And that always happens.

Just yesterday, I've been asking a group of architects, what is extensibility?

And I had literally a group of four people just sitting in that part of the room, I had five different opinions of what is extensibility as an architectural characteristic.

Nobody could give me a straight answer.

They started just talking about it and trying to figure out what is actually extensibility.

And that's the usual case.

And this is why ubiquitous language I find very important.

But then again, it's context specific.

So it always, it depends.

Because you go to as a consultant, and you're a consultant yourself, in that sense, right?

You go to one company, the same terminology will mean something else.

And then the other one, the same terminology will mean something else.

You need to, as that consultant, you need to adapt to that terminology.

You cannot bring your own to an extent.

Yeah.

Yeah.

Like we discussed, you come to a company, okay, so what do you mean by a software architect?

Yeah.

And then the names for a software architect, there's so many, right?

And the roles and the responsibilities and the...

Yeah, that's a whole different topic.

We can refer to a video from Mark Richards, just on that single topic, where he just rants about different roles, and the maybe general understanding of what those roles mean.

But that's a, this one actually we can put into coupling very easy.

Because that's basically semantic coupling.

Yeah.

So the connaissance of meaning.

Yeah.

So it depends.

If you're using the model.

Okay.

So if you're communicating in the same model, then yeah, that's model coupling.

Now, if you're talking to someone else who is not familiar with that shared language, and you have to simplify it, but you still have to explain what happens in that business domain.

Well, you simplify it, maybe you remember that episode of The Office with Michael Scott, when they had to explain the accountant, had to explain him what's going to happen if they're not going to spend all the money by the end of year, so next one will get less.

And he said, like, I don't remember exactly.

But he explained like he was six years old or something like that.

So that was like an integration contract.

A approximation of a model to be able to convey that message.

Yeah.

And now we're going to get independent joke in chat.

Perfect.

That's, that's what we're aiming for.

I find it the most right answer in architecture anyways, it depends.

Then we can go cracking.

Oh, well, usually, if you explain what it depends on, then that's fine.

If it's just it's annoying.

Yeah, I, we tend to talk about the seniority level of different people.

If you're a junior, you have an answer for a question.

If you're a meteor, then you'll say it depends.

If you're in senior, you'll say it depends.

And you'll start explaining on the walk.

And this is a show of, does somebody really understand the topic that they're talking about in that sense?

But that's a completely different ballpark.

Now, where were we in terms of coupling again?

So the last question was about people, about social interactions.

Yes.

So if you, if we put it in the context of Conway's law, can we explain coupling using Conway's law?

That, because that might be an interesting one.

Yeah, that's interesting.

You recall Conway's law or should I just bring it up?

Yeah, of course.

I'm not going to say it word by word.

I don't remember it, but.

Don't worry.

I have it handy.

The architecture is going, one day is going to mimic the architecture of the company, their organisational structure.

Yeah, again, organisational structure makes some people closer to each other.

So the distance is reduced.

Some are more distance from each other.

So they're not going to collaborate.

So as a result, the technical distance will be affected as well.

So I always, when I'm asked about Conway's law and I heard this story about an architect designing a system.

Okay.

So I'm designing the system.

I don't know what it's going to do yet exactly, but I know it's going to have six modules because I have six teams in different geographical locations.

Okay.

So it's definitely going to have six modules.

I don't know which module was going to do what yet, but it's going to be six modules.

So I think that puts that perspective on the social technical coupling here, social organisational coupling, because we basically looking at that, we're having that spread of teams all over the place.

That would then mean that we want to have them going separate ways or well at best separate ways, because we already anticipate the problem from Conway's law, but we might as well go consumer provider or something like that, or partnership at times if they are closer, right?

Yeah.

So in domain-driven design terms, if you have six teams, that means you will have at least six bounded contexts.

Bounded context is boundary.

You should never have the situation in which multiple teams work on the same bounded context because you want to maximise the effectiveness of sharing knowledge, of exchange of ideas, of people working on the same model.

And model is encompassed by a bounded context.

So at least you're going to have six bounded contexts.

Now, we don't know what they're implementing.

So maybe some of the teams might require even more bounded context because they're driven not only by organisational structure, but also by models.

Maybe they will discover conflicting models.

Let's say that a team implements multiple subdomains and to implement those functionalities, they need two different ways to represent real world entities.

They need multiple models.

Well, multiple models, according to domain-driven design, that means multiple bounded contexts.

And yeah, and of course you analyse the nature of those teams, how they are able to collaborate, whether they're willing to collaborate.

I would say that separate ways, it's something that you want to avoid as much as possible unless you absolutely must, just as shared kernel.

But yeah, it's, you know, everything new in our field was that we invented recently.

We just rediscovered it because people were talking about it decades ago.

It's like hype cycles.

Every time something pops up, we get to rediscover the same old things that were defined long time ago.

I'm looking at certain aspects that pop up again and again.

We've had microservices and the popularity, raising popularity of REST and JSON.

And with that, we have to rediscover all that there was already described through XML and SOAP.

And now we have AI agents and agentic ecosystems, and we're discovering APIs again, because we need APIs to serve the purpose for AI agents.

And we discovered the importance of interoperability.

And it's every few years, it's the same story, I suppose.

I've been looking at it for 15 years now, and I already see the cycles go in and go in.

It's quite interesting in that sense to look at it.

Yeah.

I would say that now we're entering the golden age of something that was introduced in late 60s, modularity.

Now, since those early days, we had trouble identifying what modularity really is.

How can you achieve it?

But there was no disagreement that modularity is important.

Now, modularity had different names.

Originally, it was modularity, then it was object-orientated programming.

The goal was modularity, but it was labelled as OOP.

Microservices, guess what?

That's modularity.

Modularity, yes.

But to be fair, on a different abstraction level.

Yes.

Yeah, that's true.

Now, we have those things that write code for us.

And those darn things are a bit stupid when they have to think about lots of things.

So, how are we going to tackle that?

Modularity!

Yes.

Oh, my.

Yes.

And we're already looking at, at least in my field, that organisations are not willing to change the way they govern data and govern interoperability.

And that already stems a lot of problems in agentic AI implementations.

Because, of course, they want AI agents without the proper use case.

But they want, because the hype cycle continues, they go on the bandwagon and they need it.

And what it turns out, that we need domain partitioning.

So, what do we need?

Modularity.

Again, it's quite interesting to observe that this is actually all the time the same thing.

But then, again, if they apply modularity without reason, then we get lost again.

Yeah.

By the way, domain-driven design, I love domain-driven design.

But what is it?

That's a way to achieve modularity.

Pretty much, yes.

Because we're basically dissecting everything into separate boxes.

Into pieces.

That's the problem with modularity, with that concept.

And it was problematic from the get-go.

Like, we need to divide a system into those components.

But how on earth do we do it?

Barbara Liskov said it many, many years ago.

She said, if you take a system and decompose it into components, arbitrarily what you will get is not modularity.

You will get a distributed monolith or a big ball of whatever.

You won't get good design.

You need good reasoning when you're decomposing a system into components.

And that reasoning, for me, at least, it was elusive until it kind of clicked and then the coupling book came along.

We have knowledge, we have distance.

That's it.

If we absolutely have to share knowledge, there is no way to avoid it.

We have to share lots of knowledge.

Things will change together, bring them close to each other.

That's what usually is called cohesion.

If, on the other hand, the knowledge that is being shared across boundaries of components is low, like they're not really related to each other, increase the distance.

They won't change together.

Put them in different components.

And yeah, so modularity is that relationship between distance and knowledge.

And its goal is to manage the cognitive load that you will have to experience when you will have to modify to change something in that system in the future.

Now, I just wish right now that I had handy your deck from balancing coupling and software design the training on O'Reilly, because you have this absolutely wonderful slide about cohesion, coupling, and distance.

You know, the four quadrants that you have?

I can describe it.

I remember it by heart.

Yeah, I know.

Go ahead.

In the middle of the night, yeah.

Let's take knowledge and distance.

And for the sake of this example, for the simplicity sake, let's say that we're treating them not as a spectrum, but as a binary value, high or low.

So, let's say we have two components that share lots of knowledge, but the distance is low.

So, knowledge high, distance low.

In that case, we have to look why they're sharing lots of knowledge.

If that's because of the business requirements, and there is no way to evaluate it, okay, that's fine.

We'll leave it.

Now, that relationship is what we call high cohesion.

Things that are related, close to each other, low distance.

On the other hand, let's say that the knowledge is low, and the distance is high.

Again, things that are not related, far apart from each other.

That's what we usually call loose coupling.

Now, the other two are all about complexity.

These two were about modularity.

The other two combinations are about complexity.

So, the first one, and the trivial one is, what if we have two components sharing lots of knowledge over large distance?

Guess what?

There will be pain in your future in that case.

You have to do something about it.

Either lower the knowledge, if that's possible, if not, the distance.

So, both are high, you get what we usually call tight coupling.

Now, the most, let's say, yes.

Found it.

Yeah.

The trivial one is when both are low.

When you are not sharing lots of knowledge, so things are not going to co-evolve.

But on the other hand, the distance is low as well, so they're close to each other.

Now, if there are only two such components, who cares?

Now, if you have like a bit more, like let's say 10 such components, well, you are on your way towards like good old-fashioned mouth lathe or big ball of mud, because you have unrelated things in the same basket, pretty much like my room here.

If I would show you the stuff I have here.

So, you already have seen Terminator head and I have Formula One wheel over there.

The same here.

The view you have is the clean view.

The rest of it is just pure chaos.

Exactly.

That's the one.

I mean, rubber duckies all over the place or Lego blocks for modelling.

There you go.

You need to have a rubber ducky, right?

Yeah.

Perfect.

So, yeah.

So, lots of modules close together with sharing of knowledge.

We have a big ball of mud.

They're just unrelated, just occupying the same space and it's a problem.

That leads to confusion.

Yeah.

They will eventually, those two relationships, the complexity ones, when both are low or both are high, when you will have to change the system, it will increase the cognitive load.

You will have to look for things far apart that need to change or you will have to make your way through something like my room here, which is a hell of a cognitive load, if you ask me.

That's something that is not modular.

And I believe the next slide is exactly on this.

Low knowledge, high distance is modularity.

Low distance, high knowledge is modularity.

The rest of it is just pure complexity that doesn't serve anything.

By the way, thank you, Philip, for bringing up cohesion in the comments because that's what sparked me into finding these slides.

Definitely something worthwhile because this is what we're looking at in terms of coupling.

Do we have actually modularity, which is great, or is it just complexity and it's added complexity that we don't need in this place and should be refactored and moved away somewhere so that we manage that complexity properly?

Because I do like to quote, and I literally quoted that yesterday from Don Norman, the designer of Everyday Things, it's not the problem that we have complexity.

Simplicity is something that we should really look out for and not have because simplicity is not there in real life.

All the problem domains that we're touching, they're never simple.

They're complexity.

The problem is confusion, and we should look for managed complexity, and the managed complexity is something that we want.

Otherwise, we just have complexity, and it creates confusion, so big bowl of mud, spaghetti architecture, these kind of things.

All right.

We're going to make a small pause in the topic right now.

Vlad, did you have a moment to think about the question or what would we be doing right now in terms of the prompt that we had in our private chat?

Yeah.

I have no idea what question to ask.

All right.

Just to give you an idea, Vlad actually has vouchers for the digital version of balancing coupling in software design, and very generous, we have ten of them.

So there's plenty to go around.

Now, how should we distribute them amongst our viewers tonight?

What do you think?

Best dad joke?

Yes!

Yes!

All right.

So, dear audience, please, on YouTube, because YouTube we can actually showcase in the stream, because integration with LinkedIn comments failed today, ten best dad jokes we receive in the next 20 minutes, get a digital copy of balancing coupling in software design by Vlad Kononov.

Three, two, one, start, and I see Philip is already trying to figure out a dad joke, but Philip, I believe you do have a copy already, or am I mistaken?

We have a shared library of books in Bridging the Gap, and Philip has access to all those books, so yes, there's plenty of books there already.

But let's give people a chance.

All right.

Going back to coupling.

So, of course, we have, we talked about distance, we talked about the knowledge shared, which are two factors of coupling.

Then we have a further access to the puzzle, right, because we're operating in coupling, at least in your model that you describe in the book, we have three axes, well, three characteristics that we need to look out in terms of coupling.

So, the last one is volatility, right?

Yes, that's true.

So, the model that we discussed before the prizes section was kind of idealistic, like either something is modular or something is complex.

Either something reduces cognitive load or it increases cognitive load.

And the question is, let's say we have something that does increase cognitive load, but do we necessarily care about that?

Because again, if you look at domain-driven design, sometimes domain-driven design tells us we don't care, separate ways, we don't care.

From technical standpoint, domain-driven design says use those advanced patterns like aggregates, event sourcing, where it matters most in core subdomains.

Supporting subdomains, let cloud do its thing or outsource it or just some rapid application development framework, something quick and easy, something that will just work.

So, we have to introduce that healthy pragmatism into our decision-making.

And we can do it by looking at the source of shared knowledge.

Let's say that we have that relationship of both values are high, high strength, lots of knowledge and high distance travels across, let's say, systems or services.

Now, if we will have to change that upstream component, the source of knowledge, well, guess what?

Probably the downstream will change as well.

So, the question we can ask is, will it really change?

Because maybe that's a legacy system that nobody cares about.

Let's say that many organisations have that old legacy system that does its thing, people are afraid to touch it, but sometimes you need to integrate with it.

So, if it's not going to change, if it's not volatile, well, use some of its implementation details and use them for integration.

Go to its database directly and take whatever you can, because that schema is not going to change.

So, basically, that what we are doing right now is we're bending that ideal modularity thing and saying, okay, we don't need modularity in this place.

And it's all about volatility, because that part of the system is not expected to be volatile.

Now, legacy system is probably an extreme example.

If we go back to domain driven design, then we have those three subdomains, three types of subdomains.

Core, they will change the most.

You have to assume that high volatility there, and there is no other way around it.

Supporting subdomains, nobody cares about them.

They will change rarely.

And if they change, those changes are going to be not that dramatic.

Unless, of course, there's a big change in the organisation, and supporting subdomain morphs into a core subdomain.

Then you have to redesign everything.

I have a caveat to that.

Yeah.

Actually, one of the systems that changes the most in large IT ecosystems is the integration platform, and it's in the supporting subdomain most of the times.

And integration platform has the most volatility, or interacts with the most volatility.

And it's a supporting...

Can you give an example?

Yeah, that's an interesting case.

Okay.

So, when I work on the integration platforms, and what we do, especially if we do API led architecture, which is three layers of abstractions, those layers of abstractions are there to support composability of services.

So, we can compose new services, new business functions based on the exposed data in the adapter layer, and then the composition layer gives us that we can compose that data objects into services, whatever those services may be.

Now, if I have the providers of data just behind the domain systems, just behind the adapter layer, whenever they change anything, the impact hits the integration platform, but not always hits the consumers of those services, because we just mitigate that impact of changes on the consumers, because we hide that impact within the adapter layer, the composition layer, and the channel layer.

And different changes impact different layers of abstractions in the integration platform on its own, not necessarily impacting the end consumers.

So, let's say we have five consumers consuming one service in the integration platform, and one of them needs more data in the response.

So, we make changes on the provider systems, on the domain systems that are upstream.

I'm never going to get used to the upstream downstream, but provider is upstream, right?

Yes, yes.

Okay.

In the upstream, we make changes on the upstream, that changes trickles through the adapter layer of the integration platform, the composition layer of the integration platform, and then is exposed in the channel layer only to that specific consumer, while the rest remain untouched, because we have that ACL in the channel layer that bars them from being impacted.

So, actually, all the volatility of all the upstream systems is then squished into the integration platform and mitigated so that it doesn't reach downstream.

That, I think, is an exception to a supporting domain being less volatile.

Thank you so much for saying that, because you naturally led me to the next topic I wanted to talk about.

Perfect.

Because volatility can be natural.

Yes.

So, the volatility that is caused by the business domain, and it can also be, let's say, inferred or accidental.

Now, let's say that you're a supporting subdomain, and you depend on a core subdomain, and that one, the source of the knowledge, is volatile, and its boundary is bad.

So, all those changes propagate across the boundary to the downstream, and that makes your supporting subdomain volatile as well, but not because of the nature of the business, but because of the design, because of the way that upstream doesn't care about its knowledge spilling outside of its boundary.

It basically introduces that situation we discussed earlier.

High knowledge, high distance.

That's exactly the case.

Yeah.

Precisely.

Yeah.

And at times, we take the integration platforms, and when that upstream system doesn't care about knowledge spilling, we put a barrier as the adapter layer, so that knowledge doesn't spill.

So, we actually put all layers of the integration platform are essentially anti-corruption layers, and they have a different function in terms of anti-corruption that they serve.

The channel layer barring the consumer systems for the knowledge of the integration platform spilling out to the consumers, the composition layer barring the knowledge about individual upstream systems spilling into the channel layer, and then the adapter layer hiding that whatever is the logic, the access logic, the data, the data models of the actual upstream systems.

And this is exactly that cascading spill that we're just blocking with dams of abstractions.

And of course, different integration platforms, different number of

abstractions, because if we go to broker architecture, and there are integration platforms

that are in that specific architectural style, they have a single layer of abstraction, and it's

very hard to give more, and then the problem of solving coupling and problem of solving volatility

becomes a little bit more trickier, still manageable.

But again, it depends on what the company needs.

Yeah.

Again, I love that.

First of all, that's an example of a great implementation of anti-corruption layer, the domain-driven design pattern.

Second, it's a great illustration of the balanced coupling principles and what happens when they're broken.

It also explains how balanced coupling can help you to identify and guide you towards a solution, which is to introduce the integration contract, which is anti-corruption layer.

Love that example.

But I will just go back to the notion of subdomains.

I'm not joking when I say that what you described in the book is like 50% of my work.

It's true.

It's just basically managing that coupling, managing that complexity, pure essence of it.

Yeah.

Okay.

Going back.

Yeah.

So what I meant by volatility of subdomains is the natural volatility, not the accidental one that can be caused by poor design.

With poor design, yeah.

If you implement a big ball of mud, then yeah, it doesn't matter.

If it's supporting generic core, it doesn't matter.

Everything will be volatile and everything will change together.

That's very much true.

Yeah.

So if I look at system-to-system integrations, well, if we have point-to-point or even driven architecture, that usually is very hard to control that volatility.

That's usually always high impact and a high degree of coupling.

So we experience not only contract coupling, but also going into model coupling very often.

But if we introduce integration platforms in between, that we can have that more refined control over that volatility and how it influences, impacts the other systems, meaning domain systems, because the integration platform itself is not a, well, not a domain system from a business perspective, right?

It's a supporting system.

As we already agreed upon.

Well, it depends.

In some cases it can be core.

Yeah.

We already established that somewhere close to the beginning of the stream.

Now, Philip is asking, have I shared the riddle for Eric Evans?

And yes, we did talk about the riddle before the stream.

Quite a nice story on its own about exactly integration platforms and the purpose of integration platforms in a sense of domain-driven design.

But I think I told this story too many times over the stream that I'm not going to repeat it again.

And we're still waiting for the dad jokes.

There are still plenty of room in the comments for the dad jokes.

I think we have about four now.

So, if you do want to receive the book, then please do add the dad joke in.

Okay.

Where were we coupling-wise?

Volatility, for the degree.

What else can be?

Sorry, Carol, I'm just sharing here a quote that you reminded me about.

I'm sharing here in the private chat.

Yes.

I'm going to put it in captions.

Give me a second.

There we go.

Yes.

So, any third-party system that I have to integrate with was written by a drunken monkey typing with his feet.

Oh, my.

I think you're hitting the absolute sense of my work at this point.

The number of really badly composed APIs, definitions, behaviour of APIs that I've seen over the years really reflect this particular quote.

Yes.

You hit the spot.

Nailed it on the head.

Oh, dear.

That's very true.

Now, since we have our colleagues from SAP, somewhere in the chat, they were quite active.

I don't know if you have ever worked with SAP R3, because now the current standard is SAP for HANA, which is a very nice, rounded system.

But R3, the way older version of it, you couldn't integrate that without an SAP specialist present in the room.

Because, yeah, that was definitely a job that secured you for life, in that sense.

Because the interfaces of SAP R3, all the attributes were named as abbreviations of German words.

They were not decipherable for anybody who was not in the SAP ecosystem.

So, this is exactly the essence of the drunken monkey typing.

Because you could not understand that.

That reminds me of MicroTik routers and their interfaces.

MicroTik routers.

Please tell me.

I have no idea what that is.

Oh, so that's a router that some consider like a consumer device, but to configure it, you need a person that specialises in that thing, because its user interface is next level.

It's like Windows 3.11, Battleship Grey, and it's full of, like you said, those three-letter acronyms.

That thing works like, I don't know, like it's bulletproof.

You configure it once, and it will work forever.

It doesn't need no maintenance, but to configure it, wow.

Yeah, that probably is quite an issue.

And this is, again, literally, we're in the aspect of coupling, because that's the connaissance of meaning.

We have the connaissance of name and type, where we already screwed up on the connaissance of name.

We maybe not screwed up on the connaissance of type, because maybe the types are actually, let's say, well-defined in the contract.

But then, if we screwed up on the connaissance of name, how can we even go into the connaissance of meaning, which is something that we actually very much need in the contract coupling, right?

Because we want that contract coupling.

This is something very much wanted, because we want to convey the contract that has a meaning, and we can use the shared meaning of data.

And then, how can we even convey that, right?

Again, landing in the coupling area.

Yeah.

Yeah, even with contract coupling, we can still make it hard to work with.

Again, from the modularity perspective, that interface won't reflect your implementation models, won't reflect your functionalities, implementation deals.

In fact, it can still be a very hard decipher.

So, we have connaissance of meaning, where you can communicate by exchanging magic numbers, for example.

That's one way a connaissance of algorithm can make things a bit more complicated.

There is a famous example from the original book about connaissance, when it was introduced.

Miller-Poe Jones used the example of a system that returned a sorted array of values and numbers for some endpoint, but because of the bug, the last two values were always in inverse order.

So, the consumers, when they received that, they had to do the same behaviour, the same algorithm, to take the last two numbers and reverse the order, and now they have a sorted array.

So, that algorithm was conveyed, and it could be conveyed across integration contract.

It still could be possible.

Yeah, but we're adding...

Well, it is a connaissance of algorithm, but then if they didn't know it through the contract, then basically we're looking more into the functional coupling, right?

Yes.

Well, yeah.

Literally.

They figure that out.

But, yeah, that's an interesting point, because once they fix that bug in the upstream, that functionality has to change in the downstream as well.

Otherwise, guess what?

The integration won't work.

So, yeah, that's a very, very good point.

That's borderline functional coupling here.

And they fixed the functional coupling, and then we back to contract coupling, but by fixing it, we introduced impact, change impact, into all the consumers, which is, again, heavy.

And going back to my lovely example where I screwed up something by namespaces and exposing the model coupling to a consumer, and it took me four years to fix it.

Yeah, we fixed it, but it took real effort and a really big project to incorporate those small fixes of those namespaces.

The namespaces that was just one line in an XML.

Well, XSD, precisely, but one line in an XSD that needed fixing.

But because of that, we introduced a lot of brittleness, and it cost us four years of that contract brittleness to be able to really fix it, because we couldn't develop those services independently.

They always have to be developed with all the consumers in line consuming the same services.

That's horrendous.

And then here we have a great example of even deeper form of coupling, which is functional, because the switch of the sorting.

Oh, man.

So now I hope everybody can now see how these really small things can really introduce very tight coupling, and that's why we do need those anti-corruption layers that really solve those problems.

But what is an anti-corruption layer?

It's just a layer of abstraction on top of that.

What is the logic of that system, really?

Or the open host service being that layer of abstraction on top of that.

And to quote, again, quote attributed to Neil Ford here, nothing solves an abstraction layer problem like another abstraction layer, in that sense, because that's basically what it is.

We have an abstraction layer of the system where we screw up something functionally, model-wise, whatever, and nothing can solve it like adding another abstraction layer like that ACL or OHS on top of it to fix it.

That's where domain-driven design helps us with context mapping to just try to find out how we can balance those relationships so that they can work.

And, of course, somebody consuming the OHS can conform to it, right?

They can.

Or they can have an ACL to mitigate those changes, because that's, again, we can couple tightly into that model of that published language and still have a problem, because we then have that coupling to that of that published language.

And is that okay?

Again, it depends.

And we already explained that it depends on distance, volatility, and all those factors.

And that's a difficult, I think that's, in general, a very difficult balancing act to be had, how to deal with that, right?

Yeah, that's why I think we are safe.

Like, Claude, I'm not afraid.

I'm still not afraid.

A few weeks ago, I had to look at a codebase that was written primarily by Claude, and we are safe.

Yeah, and I've seen plenty of discussions on the topic, and why we're safe is because those models will return an average, or they will return a list of options.

And who is going to decide which option is the good one?

Because not that model, definitely.

You require a human being, so you require an architect, somebody that actually understands the dynamics and all those dependencies on all those different abstraction levels, because it's not one abstraction level, it's multiple abstraction levels that we need to factor into that decision.

Yeah, and I like to define Majovari as design of a system that not only achieves the system's current goals, but also supports future goals.

Future goals that might be required from that system, like reasonable future changes.

The difference is, if you have a big ball of mud but it works, that works, but it's not modular.

Now, once you make it modular, then it not only works, it will serve the business in the future, serve the company, let it evolve in the future.

Now, what are those future goals?

Is it any kind of change?

No, that's not reasonable.

We cannot do a system, design a system that will allow all possible changes, like even turn a CRM system into, I don't know, a game or something.

We don't want to do it.

We want to focus on reasonable changes, like reasonable change vectors that are specific to that company, that period of time, that specific context.

And currently, the way I see it right now, that's something that we know.

And AI is, at the moment, too dangerous to trust with.

Then again, I don't know, five years ago, if you would tell me that I will have AI running, supporting subdomains for me, I wouldn't believe you.

So who knows what's going to happen in five years?

Yeah, that's probably very, very non-deterministic what's going to happen.

The AI industry tells us one thing.

The reality tells us something completely different.

The hopes and dreams of CIOs, CTOs, CEOs tells us another thing.

And the complexity of what we're dealing in terms of coupling and designing architecture, building the right software for the job tells us, again, completely different things.

And then we go to Barry O'Reilly, who will then tell us about residues, and that he's very happy that people are using AI, because that will give him a lot of work in the coming years as an architect, right?

So, yeah, I think all of these are, to an extent, true, that these things will happen.

But again, it depends.

It depends on so many factors.

Can they happen in these areas that we work in?

It's ridiculous to even try to prognose that at this point, because it's just too little facts and too many hopes and dreams in that area.

And I don't think that in terms of the level of complexity that we're seeing and we're tackling with balancing coupling, with integration architecture, with all those decisions that we make at a large scale, I don't think that this is a reality that these things will come to play in the next few years.

I think this is still, they don't have the right sources to learn from.

So, this is not even possible for them to even figure out, because that would mean they need reasoning capabilities.

And we know that there is no reasoning capabilities.

That's just statistical relevance at this point.

So, we literally talked about that last week, just to make it clear.

So, if somebody's interested in the ponderings on relevance of AI in development, that's last week's stream.

You can watch it on YouTube.

Just drop into that and rehash that, because that was the whole stream only about that.

Look, just to put things in proportion.

So, my hobby is making a laughing stack out of code written by AI.

At the same time, I'm not giving away my chatGPTN cloud licences, my subscription, sorry.

I'm not giving that away, because that thing made my life so much easier.

Very much true.

Same thing.

I'm not giving away my Gemini subscriptions, because it just makes my life so much easier, if you know how to use it, right?

Yeah.

We just need to know what it depends on, where we can trust it will make the right call, or where we better work ourselves.

Only always, in that sense.

That's the part of the common sense of the DDD that DDD promotes.

I think that's something that's quite important here, and this AI literacy at this point.

But that is with everything.

Microservices, we do need that microservice literacy as well, when to use microservices, how to compose those microservices.

Should we do fine-grained or coarse-grained?

That's that literacy that comes into play that is very much needed.

Otherwise, we will not be able to do that.

And AI will not help us in that kind of decision-making, because it doesn't have enough context.

I hope not.

I try to ponder upon that, how much context you need to build up

for Gen AI, and I looked at the context I'm gathering as an architect to make architectural

decisions, and just the sheer number of abstraction layers that I need to touch is overwhelming

to put in an AI, because it's just those abstraction layers are so different,

dependencies-wise, because we're looking at the business level of business requirements,

business needs, business wants, then we look at translating that to business processes,

that's another abstraction layer, then we're talking about translating that into architecture,

that's another abstraction layer, then we're talking about translating that to

development, to tests.

We're just riding that elevator up and down all the time.

If you put all those abstraction layers into LLMs or one AI agent, that's hallucination waiting to happen, rather than it being able to produce something, because this is just too much.

Today, what's going to happen in five years, in two years, I'm afraid to make predictions, to bet on something.

I'm only betting on sustainability, because right now, if you look at OpenAI, they're losing money because of sustainability of the solutions.

If you look at companies burning through tokens, again, sustainability of those solutions.

In that sense, I think our knowledge about understanding, coupling, understanding those dependencies, being able to answer it depends, that's the crucial part, because we're more sustainable than those solutions.

Yeah, that's an interesting way to put it.

Yeah.

This is the one reason I think that AI will definitely not replace us.

All the other reasons are questionable.

Unless we find an infinite power source, then we're good for the next few years.

Here, we have exactly to the point, because I'm building a new PC right now, and this is my nightmare, that Stefan mentions.

The cost of DDR5, DDR5 now costs as much as a good chipset, a good graphical chipset.

I never figured five years ago that RAM would be so expensive, and that's exactly the point, right?

That's exactly the problem in that sense.

All right.

We're still waiting for a few more dad jokes, so if you want the book, please do post a dad joke in the comments, because I don't think we hit 10 yet.

Otherwise, we'll be, well, we've been at it for two hours.

I believe we did not touch upon everything coupling-wise or everything DDD-wise.

There's plenty more to talk about, but personally, my common cold is getting to me, so I'm dying here.

I drank the whole jug, but it didn't help that much yet, and two hours is a lot of time.

I know that you, Vlad, after four hours about talking about coupling, you're already dead yourself, so two hours is quite a lot, so last chance for anybody else to drop in a joke, and let's get into a few and unmark them with stars.

Let's see what we got.

So, Stefan, we have Sodium.

Yeah, okay.

Okay, good one.

Yes, well, that's a meta-joke of dad jokes, I suppose.

We have a very nice one tied to the theme of the domain-driven design.

What do you think, Vlad?

Yeah, good one.

And continued, that they finish each other's stand-ups.

Oh, man.

Woo!

That hits good.

I think that's a good dad joke.

How about you?

Yeah, that's like two jokes in one.

Two jokes in one, definitely, yeah.

That definitely deserves a book.

Taking the it-depends architectural spin on romance.

Okay, let's see if we have anything else there.

Well, Philip, despite having a copy, I think he wants to go again for another one.

I think Philip can gift the book to somebody in the SAP ecosystem for them to actually understand what coupling is.

They have plenty of coupling there.

Don't tell anybody.

No, but we see when we use, that's the business model.

When we use SAP systems, we understand how much coupling there is.

Not everybody who buys SAP products understands how much coupling there is, and then they leave it for the techies to figure it out.

And we do.

I meant the old implementation, the one with German words.

I think there's plenty of couplings without the German abbreviations of words in the data model of, in the published language.

There's plenty more to be had without that.

So, that's still fine.

Let's see.

Do we have any other?

Now we have only people laughing at the jokes.

So, okay.

You know what, David, that asked the first question, let's add him to the list, because I love the question.

Okay.

We get David into the list.

All right.

We'll contact David as well.

All right.

Okay.

Anything else that stands out that we can, anybody else that stands out that we can add to the list here?

Sorry, I couldn't keep track of all the messages.

When I was busy talking, you know, I'm single threaded.

Fair enough.

I mean, if I look at this comment, yes, that's a dead joke right here.

That's the painful truth of our existence as architects and consultants, but at the same time, personally, I find it extremely funny.

Because at a certain point in terms of stakeholder management, all we can do is just have a laugh about it, because it's not even a healthy kind of laugh, it's that panicked, cringy kind of laugh where we are just faced with the reality of things, and we cannot do anything more.

All right.

So, Toasty, you get a book.

Let's see, you said David.

All right.

So, we're going to put David on the list.

Do we have any more?

Ah, right.

We have a repost of a comment.

I didn't realise that would be really a dead joke from my perspective.

But maybe.

Or maybe it just didn't hit me, but apparently it hits you very well.

So, yes.

Okay.

Yeah, definitely.

I missed that one.

Thank you for reposting that.

That's definitely something we need to put in.

Fair enough.

Let's see.

So, all those people mentioned, you all get the book then.

You all get the copy of Balancing Coupling in Software Design.

Well, I think that some of them are really good.

Especially this one.

This one, you say, okay, long knowledge and distance, that's how my team works.

That's not a bad joke per se.

That's just the reality of things.

That's the best progressive level of champions.

That's a fast track to a bowl of mud.

Oh, we could go on and on in those.

I don't want to bring the video from O'Reilly into it, but there was a lot more of those that you did as well, right?

Oh, okay.

Then Philip confirms that he'll send a voucher to somebody at the DDD community in SAP.

I think that that will definitely help that community improve.

And Philip is doing a great job at that, talking about DDD in the community, and it's getting a very, very nice traction in there, just to be fair.

They're trying.

They're building competencies.

There's 40,000 people trying to learn DDD within SAP, and I think they're doing a really good job at getting traction of domain-driven design and understanding coupling within that.

So, hopefully, we'll get better products.

Hi, Philip.

By the way, I know Philip.

I think- Yes, you do.

Did Europe, at least, and I think we had a few chats online.

Well, precisely, DDD 22.

There we go.

And this is one of the reasons why Philip and I actually did a workshop at DDD 25, because you encouraged Philip to go out there.

So, yes.

So happy to hear that.

Thanks for sharing.

We might not know, but actually what we talk about really, at times, inspires people and changes people's approach to reality and sharing and building competencies.

So, the more, the better.

Yeah, exactly.

All right.

I know we can talk for hours on the subject, and there's more coupling to discover, especially if we dig deep down into code, into modules, into relationships between different aspects of systems that we do.

But I think that may be a topic for a different day than today.

So, dear audience, and there's plenty of people still watching us, which is after two hours is not always the case.

So, I'm really happy that there are so many people still watching.

Thank you for joining us tonight, and before we all go, in a week, we're really continuing the problem of coupling, because we're going to be talking about tackling complexity with semantic metadata, and Marty, potentially, and he's a very nerdy and geeky guy, and I absolutely love the guy for it.

He is now trying to write a piece of software based on his current code base that could be actually used as an analytical tool, and I encouraged him to do that, and he went for it.

So, hopefully, he'll manage, because he had about two weeks for that, and a week has passed.

So, that's going to be interesting if he manages.

If he doesn't, we're still going to have an absolutely amazing session about semantic metadata, because that's his bread and butter in the integration world, and he already has some interesting insights.

Now, of course, if you want to learn more about what we do at Bridging the Gap, visit the site.

You can also see all the upcoming events by scanning the QR code visible to the left.

Philip and I were running also a very nice training at DDD Academy this year, so we're talking about how to utilise DDD strategic and tactical patterns to design interoperability between systems, which is basically what we talked about today as well.

Well, not the design part, but at least the understanding the dependencies part.

And then, of course, if you're new to Bridging the Gap, and the loosely coupled live streams, please do subscribe to the live stream, to the channel on YouTube, and there's a QR for that.

So, Vlad, I suppose how we're going to do that, just to let people know, please, I think everybody ping me the emails on my LinkedIn, in a private message.

If you don't have me on LinkedIn, please add me on LinkedIn.

I'm really easily findable, and then I will relay all those email addresses of the winners to Vlad to distribute the codes for the book.

Does that sound reasonable?

Yeah, perfect.

Fantastic.

That said, everybody, thank you for the amazing comment section tonight.

That was absolutely great.

Vlad, thank you for joining us for this session.

Absolutely wonderful to have you here.

Hopefully, not the last time.

Thank you so much for having me.

That was an amazing conversation.

I really loved it, and, yeah, I hope that's not the last time.

Awesome.

We'll find a more specific deep dive topic for the next time, just to have more fun in nuances.

All right.

Fantastic.

So, thank you, everybody.

Have a great evening, afternoon, and, well, wherever you are, or maybe a morning.

I don't know.