...

Microservices and Domain-Driven Design — The Strategic Parts

Originally aired:

About the Session

We live in a world of microservices. Yet, what is a microservice? What defines the boundaries of a microservice? How do we define the relationships between microservices? Thankfully domain-driven design gives us the concepts and practices to better design and decompose our services.

In this session we will consider many of the concepts of DDD — How bounded contexts use Ubiquitous language to model the domain, how context maps can be used to establish the interconnections between services as well aggregates and domains events, all of which will service us well as we go about creating our microservices.

Transcript

Morning, it seems like a lot of folks here are from India, so it's always a privilege. I just want to introduce ourselves. Say hi, show my face, introduce myself really quickly tell you what this session is all about. If everyone can hear me just, you know, give me a shrug or a thumbs up in the chat, and we'll kick this session off.

I know people are sort of mingling around in their boots. so what are we going to talk in this session? This is actually a two parter. I'll be doing this session now and I'll be coming back at the end of your day. Sorry, tomorrow from the end of the day for you today, to do the second part, which is the Domain Driven Design and Rubber Meets the Road, which is more of the tactical session, as compared to this one being the more strategic one.

What I'm going to talk about? I'm going to talk about why we need Domain Driven Design in depth. Why is this such a thing? Especially in the world we live in, which is Microsoft's, right? And then, we will talk about some of the terminology, you know, things like domains, sub-domains, and then we will get into what we call the strategic patterns of Domain Driven Design.

And then I'll close off with some architectural insights. What Domain Driven Design lends itself to. And hopefully that will bring us to a nice 50, 55 minutes. A good baseline for taking your knowledge to the next level when it comes to Domain Driven Design. Yeah? So what I'm going to do is I'm going to turn off the camera because it's [inaudible 00:01:46] sort of lens, but I'm going to keep an eye on the chat, feel free to drop any questions you have, and then if you can't hear me or whatever, I know Dilip and the team are [inaudible 00:01:58] just reach out and say, you know, "I'm having technical issues", and I'm sure they'll figure it out. Alright? So looking forward to an excellent 50 minutes, let me turn off my camera here.

And let's get started. Right, so, Domain Driven Design. Very quickly, let me introduce myself: my name is Raju. I am based in the United States. so right now it's nine o'clock at night for me. I am an independent consultant. I do a lot of training and speaking and I've been at GIDS for a couple of years.

And you know, this is an interesting one, with it being virtual. But I did want to mention just one quick thing: I am @looselytyped on Twitter. So if you have any questions after the session is over, or you just want to say hi, please reach out, and I'll be more than willing to tell you or meet up or answer your questions.

So somebody has asked me about the agenda. The agenda of this topic is very quickly: What is Domain Driven Design? What do terms like the domain and sub-domain mean, and how do they translate into what is referred to as the strategic patterns of Domain Driven Design? So things like, what is the bounded context? What is the ubiquitous language? What is context mapping? How do all these fit together? We'll talk about how to establish the seams of your services, and then we will talk about the architectural insights that you can sort of draw out of Domain Driven Design. Right? So hopefully, Sauvage, that answers your question.

So, first of all, let's start by asking ourselves: Why do we care? Right? Why do we care about Domain Driven Design? So here's your Greenfield project, right? You have a great, nice, clean, you know, everything is working. Anytime some change has to happen, you can see where the changes will go through your application, right?

So let's say this is some kind of a layered architecture. You still have nice clean boundaries. The boxes could be, you know, packages, modules, what have you, right? Doesn't matter. The point is you have this nice clean architecture that you are cutting through any changes, clear and deliberate. And then, you know that one fine day when your boss walks up to you and says, "Hey", let me just say, "Hey Osha", you know, "Can you make this little change for me?", and then I'm sitting there thinking, "Yeah, sure."

You know what? We didn't quite think of that one. So what I'm going to do is I'm going to go from here, and I'm going to go fetch that little piece of data from that side of the application. Right? That's just a quick hack. We just put it in. It's going to get fixed in the next sprint. And then what happens over time? You see, well, there's this other change that Dilip wants and, well, we got to go make that change and we never really thought it through before. So we're going to draw this other arrow down and then you have more changes. And what ends up happening is that fundamentally what you are doing is, you are changing what the initial landscape was, right?

Now, whenever you make a change, you can no longer clearly see where changes need to happen through the application, so what happens is every single change becomes this exercise in code spelunking, because you have no idea if you change something over here who else is going to get affected. And this, my friends, is referred to as the Big Ball of Mud, right? We've all lived this. Something that was nice and clean over time seems to start deteriorating, and fundamentally the problem we've been trying to solve in software development for a long time now is how do we get out of this? Or how do we never get into this?

So, we start thinking to ourselves, well, maybe we can make a change. Right? We can analyze the code. We can do some sort of tactical approach that will help us get to a better place. Some of you might have done cohesion and coupling analysis in your code base to figure out which packages belong to which side of the application. So maybe whatever tool you decide to pick, right? You might do some package analysis to figure out who depends on who, which are the leaf nodes in your application and which are the trunks, you know, the things that talk to everything else. And let's say that you came up with this model, right? You decided that, given this scenario, you have maybe three or four separate things, that are applicable.

So, this might be the result of doing things like solid, or, you know, you might pick ideas like test driven development or whatever. You try and figure out what are the separate moving parts in this application, and then you try and tear it apart at those seams, right?

Well, you might end up in a situation where you might actually start off with four microservices, right? What you've done is you took what your initial monolith looked like, you tactically, surgically cut it up and you made four different pieces. The fundamental issue here, the baseline that you are assuming is that you had it right to begin with, right? The problem when we start writing code is that we are always thinking like developers, right?

We come at it from a developer's perspective, so no matter how you carve it up, what you end up usually with is, well, let's take a look. You might develop four microservices and then you suddenly realize, "Oh my God, I have this microservice here, but it needs that thing from over there, so I'm just going to do a quick hack and go fetch this piece of data", right? Or go reach into that schema or do something like that.

Then, over time, what you get is... you can see where I'm going with this. What you essentially develop is a distributed ball of mud, right? So, I literally had this conversation. I was doing a training in University of Milwaukee in February and I had this conversation with a bunch of developers and they were telling me that they had twenty microservices written. Didn't know why they had 20 microservices.

Someone just decided arbitrarily, to some extent, to divvy up a monolith. And it turns out that all 20 had the same database schema being shared, right? So this is the fundamental problem, is that when we start taking tactical tools, like code analysis, static analysis, coupling cohesion, as metrics to try and find the seams in our services, it ends up invariably that you go against the grain of what this service is actually meant to do.

So what's the solution? The solution is Domain Driven Design. Now let's say you've never faced the situation, which I am pretty sure all of you have. But, let's say you've never faced the situation. We are also living in a world where we are now being forced to think about technology as a strategic advantage.

Doesn't matter what industry you are in all of these words or terms should not be unfamiliar to anyone in this room. We're talking about cloud native and serverless. He'll forward in his session, and he mentioned, you know, serverless, functions as a service. Dev ops is a big thing I'm deeply involved in dev ops transformations. Dev ops is a thing.

And get talking about shifting deployment targets. Think about how many places applications today have to get deployed on. You have mobile devices, edge devices, servers, the cloud. Even more so, there are other factors at play that are making technology a centerstone of most businesses.

Talent engagement is a big one. I know I've left organizations because they were not keeping pace with newer architectural styles or newer technology stacks. And what we have realized is UML and sequence diagrams don't work anymore. Right? We do not operate in a world where this really scales. We're talking about applications that scale globally UML diagrams cannot keep up.

So, Domain Driven Design, at its core, if you're going to take one message away from today's session is this: It's not about architecture. It's not about, tooling. It's not about how we divvy up our packages or design our microservices. It's about one thing, and one thing only. Domain Driven Design is fundamentally about catering to the thing that you cannot control, which is:

The user requirements, the business asks, right? We can change design. We can change architecture. We can go from microservices to monoliths, or monoliths to microservices or modulars or service-based architectures, we can do all of that. What we cannot change are user requirements. So how do we cater to that?

That's where Domain Driven Design comes into play. Now, let me give you the prerequisites. If you are going to think about doing an exercise in Domain Driven Design within your team or within your organization. Let me give you the constraints upfront, the prerequisites to Domain Driven Design.

If you read the book by Eric Evans, if you read any of the other books by Matt Vaughn or any of these folks, they will tell you that there are two things. You have to have an iterative process at work, when you are developing, right? So agile is a prereq to Domain Driven Design because you are never going to get it right the first time.

If you are starting to drive your design from a domain perspective, you are going to stumble fall and you have to pick yourself up again and sort of come back to the problem. The other most important thing is that you need access to domain experts. And when I mean domain experts, I mean, people who fundamentally live, breathe, speak the business language of your organization.

If you are in a group that does not have access to domain experts, and I've seen this in organizations, this effort is pretty much a failure to begin with. And the reason for that is because if you don't have access to domain experts, the Domain Driven Design part, right. Domain Driven Design part is already coming to a grinding halt.

So keep these two things in mind and for what it's worth, I was also listening a little bit to Venkat speak in the earlier session, and he said this. He said that there are things that we should learn and there are things that we need to unlearn. And one thing that one thing we need to learn is that we need to be good at both the technology and the domain.

Getting to know, getting to talk to, getting to work with domain experts is, from a personal growth perspective a strategic goal for most of us, it should be. So find a way to find the domain experts in your company, and go talk to them.

Alright. So, Domain Driven Design is basically design driven by the domain. I know that sounds redundant and you're probably rolling your eyes at this point, but I'm making this point with good reason. It is very important to understand that I am going to drive this point home for the next 35 minutes: domain, domain, domain. You need to, all of you developers in this room. Stop thinking about entity relationship diagrams, database, schema, how to write your interfaces or your entities.

I want you to stop thinking about all of that. I want you to think about the domain. You and your team operating, right? If I use the term "user", right? So as an example, I was working with a company and think about a company like Uber or Lyft, right. If you've ever used these ride sharing companies, imagine having the domain "user", right?

That makes no sense. You have either a passenger or you have a driver "user" is a completely useless domain term when it comes to rideshares. Right? So when I'm talking domain, I am talking the true domain that comes into play, in our, sort of, knowledge base. Alright, so:

What is a domain? A domain is a sphere of knowledge, right? That's the definition from the book. What it means is that the domain is basically a theory of the business. It is what happens in most organizations is that they treat us like kids. That's been my experience.

There is the business side, then there is a business analyst, and then everyone takes these big stories, carves them up into little slivers and then gives you one story at a time time. And the problem there is that you cannot take up all those slices, add them up and see the entire domain.

It's basically like taking a mirror, shattering it, and then trying to piece it back together, hoping you will get a clear reflection back. That's never going to happen. If you start from a developer perspective, all I care about is a user story. You are never going to get to the point where you see the domain as a whole. That's what I mean by the domain is the most important bit of our conversation today.

So, what is a domain? Well, the domain is actually rather nebulous. Here's what our domain looks like. So let's say you are in the insurance business and I'm sure there are folks in the audience who are in the insurance business. You might recognize some of these stones.

Now, this is not about code. This is the domain your industry operates. And then you have sub-domains within the main domain. So if you're in the insurance industry, premiums and deductibles and beneficiaries and claims are all sub-domains. Right? Okay. So when it comes to Domain Driven Design, the way you are looking at the world is through the lens of domains and sub-domains.

And when you think about it, there are three different kinds of sub-domains that have been identified by Eric Evans in the book. There's the core sub-domain, the supporting sub-domain, and then the generic sub-domain. Core sub-domains are the secret sauce of your company, right? This is the focal point of your organization.

If you are in the insurance company, your job is claims and premiums. Fundamentally, what gives you a strategic advantage. Supporting one are things that are to the side, but they're still something that you don't want to outsource. So let's take ride sharing because I'm sure most of us understand ride sharing as an example.

You know, the core domain is the ability to connect passengers with drivers, right? Passengers with cars. That's your sort of strategic advantage. If you can get enough drivers at the right place at the right time, you can grab most of the rideshares in that location.

A supporting sub-domain, maybe something like storing your personal information, like my home address or my work address. It does not really give you a strategic advantage, I mean, at the end of the day, it's a bookmark, but you really don't want to outsource it because it's personal information about your customers, right? So you want to keep it in-house, but it's not a strategic advantage.

And generic means the mapping application that your app might use. There is no strategic advantage. You can just buy out a mapping application, slap it in your app, integrate into it, and you're off to the races. So if you're looking for examples about types of sub-domains and domains, this would be the way you would do it.

Now, how do you identify the domains and sub-domains? So this is your organization. You have Accounting and Finance and Research and Development. You might have Purchasing and Sales.

How do you go about figuring out which parts are the parts that you are going to tackle the Domain Driven Design? And the answer is that you literally think of it as going back to the seventies.

So if you go back to the seventies and you think about how organizations operated, the way they operated was there was a purchasing division, there was an invoicing division, there was a shipping department.

And then, if you had to get anything done, you would take a piece of paper, you would go to one department and give them that piece of paper, then somebody put up a stamp on it. They would sign it. And then they would physically take that piece of paper and drop it to the next department.

When computers came along, what did we decide to do? Ooh, we can create one database, slap everything together in that database, and voila! What do we have? We have a system.

And that's when everything started going wrong, right? This, this pull towards microservices and bounded context is all about trying to get this sense of ownership.

So what you do is you go through your organization, or if you're a consultant, you start talking to your clients and you say, all right, you are Uber or Lyft, or you are XYZ. You are some ride sharing company. Here are the five departments that I see in your organization. Pricing; Mapping; Rider Experience, Driver Prep, and Payments.

Now you're going to ask yourself which ones of these, give me a competitive advantage over my rivals. Pricing? Definitely. That's how you make money. Mapping and geo-fencing? I mean, just buy it. Outsource it. It's not a competitive advantage. Rider Experience? Yep. Driver Prep? Yep. You want to make sure that your drivers are qualified. You know, they have a good car, yada yada yada. Payments? Again, Stripe; any third party vendor will do. As long as you can process payments, you're good to go. So, you start looking at these departments, you start asking yourself, what are the ones that give you competitive advantage.

Next, you try and figure out what the size of this thing is. Pricing is complex, I know many people don't understand this, or may not realize it, but Pricing for ride sharing apps is extremely complex. Oops! I think I'm getting a technical glitch. Give me one.

I was having a glitchy interface. I apologize. My other screen started acting all up and I couldn't see the chat window. Okay.

Now that we've established complexity, which of these sections are important from a Domain Driven Design perspective? Which domain are you going to tackle first? The answer actually lies, interestingly enough, in something that gives you a competitive advantage, but it's also medium sized, that's a good place to start your Domain Driven Design experiments.

It gives you a nice, rich environment to experiment with, something that is worth your time while not being too overwhelming. So you might notice that in my slide over here, you might notice that I have marked this as Domain Driven Design. let's see, I have marked these two as Domain Driven Design. You might want to start here, right?

This one, you know, tackle later, right? Yes, it is the one that makes you money, but for now, just let it be. We can do it in the next, you know, next attempt at Domain Driven Design. So, now that you figured out in your organization, which are your strategic advantage core sub-domains, you can now start to categorize them.

You have core, supporting, generic, and then the ones you are going to focus on are just the core. Right? Just start medium, start small, go from there. All right.

Now, as an analogy, what I like to give is this. The terminology is a little overwhelming, but it's important to use the terminology. So, people always use this term of domain and sub-domain, and then you're going to get into this idea of ubiquitous language, yada yada yada. The way I like to think about is this:

Think of the planet Earth. The planet Earth has a bunch of countries in it. These would be your sub-domains. If the planet was the domain, then each country would be a sub-domain. And then, if you think about it every country, again, I'm glossing over thousands of generalities over here, but each country has a language that they speak, right? And that language is different from the language from the country next to them.

Every country has a ubiquitous language. Within that country, everyone understands what they're saying. I know. I'm speaking to Indians for the most part, or at least a large part of you are in India right now. And I know this is not true at all in India, but just take it as an example. People in India all speak one language and, you know, your neighbors the left and to the right, you know, you have different languages.

You understand each other in your land, but you don't understand what somebody else is saying from another land. Right? So your ubiquitous language is bounded by the borders of your country. Again, I know it sounds... most of you are rolling your eyes at this point. I completely sympathize, but just go with the analogy for now, right?

That analogy broke down pretty quickly, for what it's worth. Alright. So let's talk about the patterns that the book talks about, and I want to say to everyone who has sort of joined right now. I know that, Some of you may join me later in the day. But if, of the two sessions that I'm giving, at least today, this one and the Rubber Meets the Road, which is in a couple of hours from now, this is the one to attend, right? So I'm not trying to discourage you from attending the other one, but if there is a session you're going to attend, this is the session to attend.

Let's talk about the strategic patterns, because this is the most important bit of Domain Driven Design. In fact, when Eric Evans wrote the book, after he wrote the book, a decade after writing the book, what he did was in the book he talks about the tactical patterns first, which is what I'm going to give in a few hours, and then he talks about the strategic patterns in the second half of the book. And he has come to saying that. He wished that he had either never written the tactical patterns of the book or if he had written it, it would have been the second part of the book and not the first. So this is the most important bit.

I already gave you an analogy that I hope will help you, but every sort of domain or sub-domain in your company speaks a different language. And this is the reason why many organizations who attempt to create a universal domain, it never works. I've worked with clients where they've had this sort of domain that everyone uses, and there is something called a "user", right?

No one knows what this "user" means, because Purchasing and Invoicing and Sales all have a different idea of what the "user" means. I'll give you a great example over here.

Think about ship retail. When you say the word "product", if you go to four different departments in the organization, they have four different definitions of the word "product", right?

"Product", in one case, in the case of the Purchasing department is something that has a name and a description and a price. The Shipping department thinks of it as a skew, weight, right dimensions. And then, Sales thinks of it as "How can we market this with something else?", there's this part of a product category or whatever. The point is, it is very hard to define a global domain language for your organization.

What you want to do is you want to define a ubiquitous language by talking to the domain experts in that domain, right? You walk up to a domain expert and you ask them, what do you do? Speak your language to me, and I will codify that language in code.

And the thing you have to understand here is that every country is different, right? Every country is speaking a different language. So, what you're trying to establish over here is I want to be codifying the language the business, or the domain experts are speaking, and that they understand. You are not going to bring your own, and Venkat just said this, you have to unlearn what we have learned for all the decades of work experience, right?

So, you start talking to domain experts, let's say that, you know, you will realize that every department has its own specific domain language. Each one is unique. They might use the same term differently across different domains. They might use different terms to mean the same thing across different domains.

Like I just said, the "product" for Sales versus Inventory versus Shipping means completely different things, right? You cannot create a generic interface to represent what a product means in any of these different things. Now, once you have that, this is referred to as a bounded context. So, what is the bounded context?

If you are looking for a weak analogy, a bounded context is a country. And people in that country speak a language. And your role as a developer is to take that and translate it to code. Literally, as they speak it, you are not going to provide a translation layer. You're not going to play Chinese whispers.

You are going to take what they say and bring it into code. And the reason for this, why Eric Evans puts such a huge emphasis on the ubiquitous language is because the business is driving the design, right? You can apply all of your tactical patterns to that, but the language needs to remain what-

Yes! The country is a bounded context. Very good, Ramesh! Very, very good! That's what you are taking away from this sort of section of the discussion.

And if you are interested in what the definition of a microservice is, this is Adrian Cockroft: "Microservices is a loosely coupled, service oriented architecture with bounded context."

It is in the definition, right? It's very crucial to think about the bounded context and the bounded context always has a ubiquitous language. Context is King. WIthin a context, a language is ubiquitous.

Now, the name is sort of weird when I hear the word "ubiquitous", I mean "everywhere", but that's not true. Here, it means "within the bounded context". So, the ubiquitous language is about linguistic analysis. Piecing apart what the business expert is telling you. It is not about technical analysis. Don't translate things in your head. When the user says "product", you write "product", and that's it. There's no translation layer. Don't try and map it to other scenarios.

So, now comes more terminology. And again, I'm focusing on the terminology because if we all speak the same language, then we can all come to terms with what Domain Driven Design is. The Domain Driven Design actually says there are two parts to your problem.

There's a problem space, which is the nebulous part I just talked about; the domain you live in, the insurance world; the sub-domains, claims and insurance and payments and yada yada; and then there is a solution space where now we come into play.

From a domain, we are going to create a domain model. That domain model is going to use the ubiquitous language in every bounded context. This is sort of the mapping. The right hand side is the things you and I are most comfortable with. The left hand side is the part we have to learn. Tell me about the domain and I will distill from it enough to create a solution to solve your problems. Now, typically one bounded context is typically mapped to one sub-domain.

Doesn't always work. there are the 50% hit rate over here of whether you will get this relationship right. Remember the bounded context is code. Sub-domain, is this nebulous idea of a department or division or a function in your business. So you're mapping a tactical or a technical thing to a sort of real world.

Now, for the next 20 minutes, I want you to forget persistence. Please, I'm begging you. Forget about persistence. I don't want to hear entities and relational graphs and hibernate, and ORMs; nothing. I don't want to hear any of it. Just keep that aside, and we'll talk about that in a couple of hours.

Alright. So, now that you have this idea of a ubiquitous language, how do you map everything together? Remember, you have multiple bounded contexts in your organization and you are creating a language that speaks within a bounded context, but you still have to interface with other context, you have to map stuff.

You may be Shipping, you have to get order IDs from Purchase, right? You might be Accounting and you have to get invoice IDs from your timesheet provider. How do you do that?

Well, that's where another strategic pattern comes into play, which is context mapping. Context mapping is all about the boundary between my bounded context and everybody else in the world.

This is about how are you going to communicate with other bounded context. Now, if you've done microservices, if you've had some experience with that, you've already done some of this.

That person has some data I want. How am I going to get it? In what form am I going to get it? And how do I make it so that their decisions don't influence my ubiquitous language, because we speak different languages.

Context mapping is all about trying to understand this relationship. And this relationship has costs. How flexible is this relationship? How much does it take to maintain this relationship?

Shared Kernel

Let's talk about the different kinds of mappings, that the book highlights. The first one, which is the one that many organizations sort of try and it also falls apart, which is a shared kernel. And what it means by that is that two teams have this small bit of terminology, this overlapping ubiquitous language that they are willing to share with each other.

This might be a shared jar with a bunch of, sort of entities or classes in it that have the same language that they both are sharing. The problem here is the level of coordination required. If I have to change a field or rename a method, I require to coordinate with some other team.

And then usually it also means, if you sort of think about it, every team, you know, right over here, This team is building a set of user tests right there. And then this team is building some tests over here. And that way you're always making sure that their changes don't break you and you don't break them. So there's always this sort of coordination cost that comes with this kind of shared kernel mapping.

Partnership

Here's another one, which is called a partnership. This is usually just early in projects, wher two teams realize that one without the other doesn't make any sense.

For example, let's see, think of an example over here. Let me give you an analogy. Think of a three-legged race. If you ever done a three-legged race. Two people are tied at the ankles, so you have to sort of go in sync with somebody else. So this is a relationship that two different sub-domains or ubiquitous languages or bounded context need to go lock-in step towards production. Otherwise, one without the other doesn't make any sense.

For example, if you were doing a ride sharing app, then maybe Payments and Pricing domains need to go lock-in step towards production with each other.

Customer Supplier

The next one is called customer supplier. This is the one that we all have been burned with. Customer supplier means, think of an application like a stock trading application and a reporting application.

Two separate bounded context and, I'm sorry. I was just reading the chat real quick. Okay. So, context mapping is sort of like an interface, but it's more of an understanding, right? So, in this case, customer supplier, there is some team out there that you rely on for data or for some information, and they are sort of doing their own thing.

We do whatever we want and you have to rely on that. So, think stock trading and reporting stock trading obviously is the meat of the application. They have total control on what they give you, how they give it to you. You are just sort of the submissive one in the relationship. You just have to accept what they give you, in whatever form they give you. This is not usually ideal, and what I will suggest is don't go down this road.

Conformist

Let me talk about another case where, see, notice over here: what I'm trying to highlight is that you have this language is the same as this language. You are forced to use their language in your domain.

Alternatively, what you can do is, you have this idea of a conformist, where you are using the language that your upstream gives you. Let me give you a solution to this and it becomes a little bit clearer.

Anti-Corruption Layer

Here's the solution to where you have some other team that you rely on for data, but you can't directly adopt their information.

For example, they say something is called a user in your side, you might be, it might be called an admin. Let's say you are writing a bug tracking tool like JIRA. The main application is all about tracking tickets and signing in users, blah, blah, blah. You are trying to create the admin side of the bug tracking tool.

You don't have a concept of a user, right? You either have an admin or you have an assignee, for example. What you do is, let's say they give you something like a user, you use what is called an anticorruption layer to translate "user" into "admin". So you take a user from this side, you convert it to an admin before you consume it on your side of the application. This is called an anticorruption layer and it is a very expensive, but a very powerful idea in Domain Driven Design.

Open Host Service

This you've done all the time, an open host service is basically the upstream says "we are exposing a swagger, you know, interface, or we are exposing a rest interface". The open host service is a mechanism for you to talk to them. You're relying on them and they're giving you a mechanism to talk to them.

Published Language

A published language is, again, another mechanism that a bounded context can expose data in, in this case, it would be something like a wisdom or an XML schema.

Separate Ways

And finally, you might've decided, you know what, we are going to live in our land, they're going to live in their land, and we're never going to talk to each other. This is the extreme of the sort of upstream conformist idea that I just expressed.

Ball of Mud

And then finally, this is the big ball of mud context mapping. And this is the one that you will most likely have played with. So you have, this idea of a big ball of mud and you don't want all that seeping into... you.

So, what can you do to prevent all of this muckiness flowing into your application?

Typically, you don't see any of these interface mappings that I talked about in isolation. You typically see them paired with each other.

Using Rest

Here's an example. Something like this. Let's say that you have a client, there's a service and you rely on that client for some work. You've done this tactically at work. What you do is they say, "We'll give you a rest interface, and here's sort of a swagger sort of lookup mechanism."

What you can do is, this is the part that most people don't do, which is the ACL or the anticorruption layer. So, in your client, what you can do is you can say I'm going to make a rest call, but even if they give me something called a "user", I am going to first translate that "user" into whatever makes sense in my language before I consume it.

You very rarely see this sort of context mapping in isolation. You see them combine together, but it's important to establish this relationship between contexts, because it explains many things, the most important one being how are you going to protect yourself from somebody else.

Using Messaging

Alright, so here's another one which is using messaging. So again, this is a combination of multiple things, you rely on a upstream service to send events to you, and then you might end up saying, "Okay, I've got that shipping order ID. I'm shipping, you are purchasing. I've got an order ID." I'm going to make an Ajax call or a HTTP call. So I get this event, and then I'm going to make an HTTP call to get more stuff from you using your open host service and using your publish language, but after you send me a response, I'm going to do you use the anticorruption layer so that your muckiness does not show up in my language. You translate one domain into the other domain. You translate one ubiquitous language into the other, using an anticorruption layer.

Let's talk really quickly about modeling techniques. I won't spend a lot of time on this, but there is a technique called event storming and it's by Alberto Brandolini. He's writing a book on it, this book isn't done yet, but this is a technique that you can use to start figuring out the sort of bounded contexts and ubiquitous languages that are pervasive in your organization.

And, you know, it typically ends up being a big white board with a bunch of post-it notes, and what you start doing is you start laying out these things called "events". And the nice thing about events is people, you know, your business users will come and tell you, "Oh, this happens in our system", "That happens in our system". The nice thing about starting with things that happened is that they are always in the past.

You're always talking about things that have happened, so they are always going to be there in the system. When, you know, I want to know when a trade is done. I want to know when a user clicks by. I want to know blah, blah, blah. All of these are in the past tense, so what you do is first capture those.

Then you start deciding, "Well, okay, a trade happened." Who caused the trade to happen? "Well, the user clicked 'Buy'". So, what you're doing here is you have an event being generated. Now you're trying to establish what caused it to happen and the who caused it to happen.

This is one massive whiteboard with thousands of post-it notes. If you Google "event storming", you'd be stunned at how big this can get in even medium size organizations.

Then you started establishing other things like external systems that you might be depending on, pain points that might be in the system. You know, this thing no one understands how it works, that thing takes too much time, blah, blah, blah.

You establish policies like constraints in the system. Every time the user logs in, they have to get a two factor auth event on their phone. Every time someone does a trade, you have to make sure that they have enough money in their bank account. If someone comes to the cashier with three coupons, are they allowed to use it or not use it? Those are policies, those are constraints in the system.

Then you start establishing read models. Read models are where you rely on some other system, so the user has to key in some numbers, maybe you're reading something off of a disk or a queue, that would be the read models. That would be the green post-it notes.

And then you start building these collections, and what you start seeing is the themes. So you see how this is the complete opposite of where we started with, where we started with was: "We already have some code and we're going to use tactical tools to carve them up. We're going to use package analysis or cohesion and coupling." What you're doing here is you're coming in from the other side, you pull in your business experts and you say "Tell us what you think the system does or should do. Tell me what the important bits here are, and I'm going to work my way back towards these cohesive holes". And now, you've found the true seams in your system. Each one of this is a bounded context. You may make them microservices, you may make them modular modulates. It doesn't matter.

Another very good way to sort of tease out requirements is to use Behavior Driven Development, and Behavior Driven Development is the given/when/then. And again, you can see how this, if you talk to your business experts and say, "Tell me what happens when this", they'll say, "Oh, well, you know, given the user clicks this then should, this should happen, then that should happen", so they're giving you the user, the command, the action and the event, and you can start driving everything from a business perspective.

This is a very popular one, which is called Anti-Requirements. Just to put it in a summary, the gist of this method, this is from Adam Ralph, by the way, is that, don't ask people what they want, ask silly questions to figure out what they don't want.

If you have kids, you might have figured this out by now. If you ask your kid, "What do you want for dinner?" "We don't know." "Do you want pizza?" "Oh, no, not pizza. Definitely not pizza." "You want pasta?" "No, we just had pasta yesterday." Okay. So you can't ask them what they want. What you ask them is so many questions that you eventually figure it out, what they don't want, and that is the Anti-Requirements sort of technique of finding what people really want out of a system.

Value Stream Mapping, if you've ever done this, is a very good way to figure out where the seams in your applications are, and you can apply many of these in parallel. I've seen folks do, Behavior Driven Development and Value Stream Mapping simultaneously to figure out where the seams are in the system.

So, I think I have about... I'm almost out of time, but let me just quickly talk about some useful patterns here.

Collaboration, collaboration, collaboration. You have to have the domain experts sitting next to you. You have to have them in the room with you and you have to have them driving the conversation.

You need to experiment. You are never going to get the domain right the first time. Again, no one knows these intrinsic systems inside out; there is no true global domain expert. Different domain experts will disagree with each other and over time you will finesse it. That's why the iterative approach is so important here. You need an iterative approach.

You need to be able to figure out the bounded context, and I keep saying this, I know I'm sort of repeating myself.

It is important. Sorry. I don't mean bounded context, the context mappings, right? Even if you don't do Domain Driven Design, what I want you to do when you go back to work on Monday or next week or the week after that, whenever you go back to work, you know, just look at your system and find out how many things you depend on and how many people you depend on and then try and find out the relationship between these, right.

Is it a conformist, or is it, upstream and then downstream? Are you at parity with each other? It would give you a good sense of the tensions that are there in an organization, and these tensions have to be exploited.

So in the end, if you are think to yourself, "Wow, that's a lot of work!" You got it right. There is a lot of work here. Domain Driven Design is expensive. It is very expensive. It takes time away from you. It takes time away from your domain experts. That's why it's important to figure out "This is my core domain, this is my strategic advantage, and this is what I'm going to get right."

So, focus on the competitive advantage and you might want to think about it because sustainable software, you want to avoid that big ball of mud that we invariably end up with. You want to improve testability, if you make smaller services that do one thing, and one thing only. And then, obviously, "finding the seams".

And then you will eventually end up, you know, sort of changing how your business processes might even work. There is a good chance that you might find like the pain points I talked about when you're doing sort of event storming, you might actually improve things because these things are highlighted as part of your exercise in Domain Driven Design.

At the end of the day, you might have noticed that I haven't mentioned a single word about, you know, what framework to use or what technology to use or what language to use, because the domain hands down beats the technology, you get the domain right, and then it is much easier to tackle the technical piece than the other way around.

So, at the end, please understand that this is all heuristic, it's about, understanding what tools to pick at what time, and to establish a good, sort of... think of it, like how you do anything else. If I would come to you and say, "Should you do YAGNI all the time?" "Should you do Domain Driven Design all the "time?" "Should you do Test Driven Development all the time?" The answer can be a yes to everything.

You, as an experienced veteran of the software industry, know that sometimes copy pasting code is not the worst thing in the world. Similarly, Domain Driven Design highlights some things, like which tool to use, when to use it, and how much to use it. Domain Driven Design is about heuristic. It's about putting more tools in your toolkit so that when you see things like, Oh, wait a second, you know, Shebonas and [inaudible 00:52:09] both used the word "product", but they mean different things. Ooh, there's a trigger! I know there's something wrong here, are these two different ubiquitous languages?

At the same time, you might notice some people use the same term when they're meaning different things. Again, it's all about heuristics. It's less science and more art. Right? Alright. So, all that to say, I know I'm sort of five minutes over.

Here are some resources if you want to take home with you. Let me just quickly say: I have found a lot of lessons in Domain Driven Design that even if you don't go down the sort of academic route of Domain Driven Design, you can learn a lot from its principles. So, read the books by Eric Evans and the, the first book in this list is by Eric Evans, the man who created the idea of Domain Driven Design, and I'll just quickly answer some questions.

Participant: How do we bind domains like security, authentication and authorization?

Raju Gandhi: Don't think of those as, domains, alright? There are things like cross stepping concerns that will come into play. And, for example, you know, when people talk about security, the problem with security is that in our world security itself is a nebulous thing.

What we are looking for is how to protect stuff. Technically, that solution is very different from a business perspective. Business cares about things not leaking out inadvertently, but very rarely is there a security department in your company. I'm not talking about InfoSec. I'm talking about like security as we handwave around our way through authentication logins factor auths or whatever.

Security is not something that you think of it as a specific domain. It's a crosscutting concern. It applies just like you would apply anything else today. Like logging, or metrics or telemetric or deployability or operationalizing. These are all crosscutting concerns. So don't conflate those two ideas.

Participant: How do we apply DDD on existing data model?

Raju Gandhi: So migrations, what I would suggest there is, there are, I think I saw some talks in the schedule over here talking about the strangler pattern. What I would suggest is first spend some time trying to figure out how far off from the target you actually are.

Go talk to your domain experts. See if the language you use, even remotely mirrors the language they use. If not, now you have a Delta. What do you need to start figuring out is, are there parts of your existing application that you can start modifying?

So the event storming exercise I talked about? That is you something can do any time. The context mapping exercise? You can do any time, but which parts of those actually come into your code, you can decide and say, okay, this level of this application, extricate.

Driven by domain to tackle, but I would recommend start with event storming and or value stream mapping or any of those techniques figured out how far off of the Delta you are and then establish which part of the application you want to tackle.

Not really good software tools for Domain Driven Design, it's still a very newish field. Most of it involves whiteboards and post-it notes, and I can say that with experience.

There are frameworks that sort of help you with things like CQRS and stuff like that, but I wouldn't go down that road, at least not initially.

So, to Tamir's question, I'm going to talk about Onion Architecture in my next session in a couple of hours on Rubber Meets the Road. So I'll talk about architecture then.

Participant: In a vendor to vendor system, how do you avoid the need for ubiquitous language?

Raju Gandhi: Yeah, so that's where context mapping comes into play. You don't want to avoid the need for ubiquitous language. Okay. So I'm going to talk about some of that stuff in my next session as well. I will talk about eventing and how to map that in the domain driven world. So maybe if you can join us then, or if you see the recorded session, hopefully it'll answer your question.

The axon framework is something that a lot of people have been using. I am hesitant to promote that. I'm not saying it's a bad idea. I just feel that the principles in the book should be... you should start there. Frameworks are useful when you have enough, when you have enough weight that you need to support.

If you're just starting off in this world, don't go down the framework route. You will end up fighting the framework, you will end up fighting the principles.

Alright. I'm out of time. Thanks for joining in. I hope you enjoyed the session. I hope you join me in a couple of hours. It is Domain Driven Design: Rubber Meets the Road. Till then, enjoy the rest of the conference, and I will see some of you soon enough. Have a good one.

See Highlights of
Wurreka

Hear What Attendees Say

“Once again Wurreka has knocked it out of the park with interesting speakers, engaging content and challenging ideas. No jetlag fog at all, which counts for how interesting the whole thing was."

Cybersecurity Lead, PwC

“Very much looking forward to next year. I will be keeping my eye out for the date so I can make sure I lock it in my calendar"

Software Engineering Specialist, Intuit

“Best conference I have ever been to with lots of insights and information on next generation technologies and those that are the need of the hour."

Software Architect, GroupOn

Hear What Speakers & Sponsors Say

“Happy to meet everyone who came from near and far. Glad to know you've discovered some great lessons here, and glad you joined us for all the discoveries great and small."

Scott Davis, Web Architect & Principal Engineer, ThoughtWorks

“What a buzz! The events have been instrumental in bringing the whole software community together. There has been something for everyone from developers to architects to business to vendors. Thanks everyone!"

Voltaire Yap, Global Events Manager, Oracle Corp.

“Wonderful set of conferences, well organized, fantastic speakers, and an amazingly interactive set of audience. Thanks for having me at the events!"

Dr. Venkat Subramaniam, Founder - Agile Developer Inc.