PracticalDDD: BoundedContexts + Events => Microservices

00:04 Indu Alagarsamy

Thank you very much, Suzanne and QCon for having me here. I'm extremely excited. QCon is like one of my favorite conferences. If I can't be here, I try to watch the videos. I love the Architecture Tracks and it's really awesome for me to be here. So thank you so much. And I'm just curious who here has heard NServiceBus or used NServiceBus? Oh, a few hands. For those of you who don't know NServiceBus, it's a messaging platform, a software for .NET that helps enables event-driven architecture and it's built on top of existing queuing technologies like RabbitMQ, Azure, ServiceBus, and so on.

For me, event-driven architecture and domain-driven design are like two awesome things, and when you put those two awesome things together, you can get really cool services that are autonomous. And to me, the whole deal of trying to have small services is so... they could be autonomous, so you can scale, so they can be reliable and so on. So for me, combining the domain-driven design discipline and the event-driven architecture as a technology gives you the best of both worlds.

Before I started a particular software several years ago, I worked for this company and the core domain of this company was sending regulatory notices when homeowners defaulted on their mortgage payments. And they did this on behalf of banks and mortgage companies. I joined the company about 2010, business was okay, but 2010, the software couldn't keep up with the load. You can understand why because in 2010, that's when the real estate meltdown happened and the core business was to send all these regulatory notices.

And so the software couldn't keep up with the load, and that's how I started getting into event-driven architecture to see how to scale, and that led me on a journey of event-driven architecture. What I wanted to talk about is, my family and I, we buy iPhone cases because I am the iPhone killer of the family. My my kids presented me an iPhone cell phone case for Christmas. It's true. I still have it.

But if we look at trying to model this page, we see a lot of things. We see pictures, name, description, price, and so on. If we wanted to model this in our software, so we tend to have a model for it. This is years and years of practice and we try to look at all the data that goes together and we come up with this model. But the trouble is, what is product? And the definition of what a product is, it could depend on who you ask.

For a person in sales, it's a thing that is marketable, that sells. So for them, the important thing is, how can they market it. For a person that's an inventory, it's a thing whether you have or you don't have, and that's their concern. And for a team that's in shipping, it's a thing that goes in a box, that goes from one place to the other. So depending on who is on the team, so different teams tend to use slightly different language to describe the same thing.

Language becomes important, and when you try to fit all of this in the same model, it becomes cumbersome. It becomes complex and unwieldy, and you have to deal with duplications and contradictions. Now, let's say you're buying a MacBook Air. You're wondering about the weight of the laptop. For the sales team, it's like it's a big thing and they want to try to market that as the lightest laptop or whatever. Apple is very good when it comes to branding.

Now, for the shipping team, it's like, how much does this weigh? Now, when you have a model and in this model where you have like one attribute called weight or something. The team in sales could use that same value, and the team that's in shipping could say, "Oh, okay, I see there's already an attribute for weight. I'm just going to use this." But what's going to happen is, you might have some weird use cases where like the value of the weight appears differently because the shipping team did some updates. Now you're going to start having weird behavior on some use cases.

So your system could act very contradictory and these things are hard to debug. So one way to get rid of that contradiction is having explicit fields, you could call it display weight, shipping weight, and whatever. But now, what you ended up doing is you've slightly bloated your model. And not only that, the domain team, they are not calling this as display weight, or shipping weight, or something. To them it's just weight.

So by introducing these different terms in your code, you've lost the language of the domain. Now there's going to be a difference when you try to communicate this concept with your domain experts. You're now going to have to, "Oh, this shipping weight means it's this, et cetera." So a lot of translations in your head. And so it becomes hard to communicate this as well.

Therefore unified models are not the best way to go, and so domain-driven design helps us to understand this and has this concept called bounded context. Who here knows about bounded context? A lot of hands. Awesome. So by understanding that you don't have to have one model to describe everything, by understanding that you're going to have some different spaces. I tend to think of a bounded context as a safe space.

A team has the space, and in the space, the models that live in that space, they can evolve freely. And it uses the language of the domain. The things in this model, the models in this space are logically consistent. And moreover, they tend to carry the language of whatever the domain expert school. The sales context can have a model for product and that can have weight. And that could be completely different from the model in the shipping context, which can also have weight and they don't contract with each other or there's no duplication.

This allows us to have clarity in your model and also gives you freedom. For the team that's working within the context, there's clarity in the language and there's logical consistency in your models. But for teams that are working outside of this context, they are not dependent on the models, or they're not dependent on your schema or something to make the change in their models. They're completely and entirely independent.

So you can evolve things differently and together. To me, that's a huge advantage of bounded context and how they provide clarity and freedom. The question is, how do then find this bounded context? There's a lot of stuff in, how do you identify the context? And that's the tricky part. This like several ways, and to me, this is really the tricky or the hard part. And I use some ways as a guideline.

And so one of the things that I do is, I ask myself, "Do I need to have transactional consistency when I try to update a couple of fields together?" For example, would I ever need to update the product description and the availability in the same transaction? Probably never. So if that's the case, there's a clear indication that those two things does not belong in that same context. I use that as one heuristic.

Do we need transactional consistency for updating the two fields? If not, then we don't have to. The other thing is, you could split according to the departments or teams, because if the teams have natural boundaries or rules and business behavior that they are trying to each accomplish, then that might be also a good start. And you could start there and see how it goes. and of course, things are going to evolve and the boundaries are not just like fixed lines, it's going to change based on conversations that you have with domain experts.

So you might find by having a conversation, a concept that is not like well-defined in your model, or you might find that that doesn't quite work well together. And so you might move that to a different context. So these are some of the things that you're going to learn by having conversations. The whole idea is, as you learn new things about your domain, about the behavior, about the rules, you try to take that knowledge and then see how you can factor or refactor your existing models to fit that behavior.

In this case, you've got three contexts; sales, inventory, and shipping. In each of these different contexts, you can have a model for product, which is all different and you can have the same attributes and it doesn't matter. And so by having this, you're using the language of the domain and the domain people can also understand when you refer to your model as a whatever property. You'd say, "What should I do when the weight changes?"

And you are using the same term, weight as the same term that they know and understand. There's no communication problems, so that's why it's important to try to use the language of the domain in your code. The other way is you can think about looking at the business processes that the business has. One of the things that domain-driven design really, really pushes is look at the behavior.

The interesting part of the business is in the behavior. If we can capture the behavior of the system in our code, then our code is going to be more aligned with the business. So if the whole idea is for us to write software that's very aligned to the business. If we can design our code in such a way, then when they come up with a new requirement, we can go along with those changes to add more features and so on.

So the changes and our models, we just can't get there by having one model. It evolves and as rules change, as business requirements change, we just keep learning from the domain and try to refactor our models. In thin this, it's a business process. For example, Amazon gives you $70 off if you buy the prime card. Obviously there are some business rules that involve like you buying a prime card and it involves like something in the shipping context and in the pricing context.

Now you can see that there's a lot of participants. So you can start to ask yourself, if you wanted to have transactional consistency, what things need to be together. So you can start to form your models and then you can see where it might fit and so on. Splitting the boundaries is a talk by itself, and my company has given me this link. You can access this. This is Udi's advanced distributed design course, where he talks about finding boundaries.

This is one of the talks of his course that you can have access to, which goes into larger, more detail. Just to get a quick check, we're at a place now, we've clearly identified unified models are not great because having one model to rule them all is a bad idea. And we clearly understand that we need to have different contexts, and by having different contexts models can live in the context and evolve freely and so on.

But what's the point of having all these contexts if we don't communicate between the context? So in order to have cohesive behavior for your system to be a actual system, these contexts needs to communicate. To me, that's where event-driven architecture comes in because you want to have this communication mechanism in such a way it reduces complexity, it's loosely coupled. So you can evolve it and you can scale it, et cetera. To me, that's where messages and events come in.

If we look at messages, you can classify them as commands or events. These are the two main category of messages that you can use to communicate between bounded context. If you take events, events is a message that conveys something of significance is happening in the business. And it's used to communicate like the state change from one bounded context to the other. Commands on the other hand convey intent and the commands can feel. That's the huge difference between...

If you think about events and commands, so events are something that get published, so multiple subscribers are going to receive it versus a command is usually sent to one particular service, or a context, or something. Typically, you want to use events as a communication mechanism between bounded context. You can use commands as a way to decouple, or have a loosely coupled communication style within the bounded context.

The one thing about commands is that it can fail, so... Has everyone watched 300 in this room? When Xerxes sends his messenger to Sparta, to Leonidas and say, "You shall bend your knee to Xerxes." It didn't go so well. If you think about a bounded context, they are two separate things, and they don't tell each other what to do. You can think about bounded context as like isolated things, and they do communicate, but using events.

I want to take example of a business process. Let's take just to walk through how we would do this with domain-driven design and have this sort of communication using events. The requirement is when an aircraft type has changed, the aircraft company wants to notify the passengers saying like, "Hey, you have a new booking proposal," and the passenger has the right to either accept it or cancel it.

If we were to model it, and this is example Norwegian sent me very kindly said, "Hey, sorry, we canceled your flight to Rome, blah, blah. Here's your new flight. If you want it, then you can take it, otherwise you can get your money back." A business process, if you look at it, it can be triggered by an event from one bounded context to the other. The thing about here is, so you've got the flight planning context saying that, "Hey, this aircraft flight has changed."

The booking context can now receive that event and then go and act on whatever it needs to do. The key word here is when. When the domain experts or the people in the business starts to use the language when, and then start describing something, there's usually a event that follows that you can get out of. The thing to understand here is, we said that messages help you design your systems to be loosely coupled.

So the whole point is we don't want to be coupled. However, we do have to be careful in how we design these schemas, because when you send messages over from one context to the other context, you are going to be sharing the schema. So it becomes really important what you put in those events and what you put in those messages. You could put a lot of information from one bounded context in that event, and now you are definitely coupled via the event.

What happens when you know this about this flight planning bounded context changes the schema of the event? How is that going to affect this booking context? You have to ask yourself and be very, very intentional about the data that is being shared from one bounded context to the other. Just because we use events and messages doesn't automatically give you Nirvana and happiness. We still need to pay attention to what we put in the messages and how we design the schema.

The other thing is the business process, there could be multiple messages that take spark in the process. The booking context receives the aircraft type has changed event, but then internally it might need to do a lot of things which might involve sending messages. We need to rebook this flight, and we need to notify this customer. What happens when the customer said, "No, I don't want this." Go ahead and cancel this booking. So there's a lot of events that are going to participate in that same process.

When you have a lot of messages that are participating in the same process, you might have to have state involved because based on the state like if the customer canceled, then you don't need to send the customer a rebooking email or whatever, because they canceled it. So based on the state, you are going to take certain decisions, different decisions. So it's important how we manage the state, and that's where we have this pattern called sagas and it can come in handy.

About the word saga, there's a lot of contention about the word saga pattern in the community, whether really it should be called the saga pattern or the process manager patterns. I'm going to leave that debate for a different talk. But basically, the saga pattern allows where like multiple messages can take part in the same business process. We can't have, I can't remember who said it, but friends don't let friends do distributed transactions.

And we can't have very, very long transactions. These are long running processes, so it's impossible to do that. So the saga pattern allows you to, when a message comes in, so you take whatever action you need to within that small scope of that action, you finish the action. And then you remember some state of what that happened during that part of the process. When the next message comes in, you can rehydrate the state and see, okay, this is how my business process is at this moment.

So based on the state, I might need to take a different action or send a different message and so on. So the saga pattern is very useful and the important part is it allows you to take compensating actions because you can have a very long transaction spanning all these messages. You are going to have to take compensating actions when messages may not arrive because in a messaging event-driven world, you have to accept that you're not going to have messages arrive. So you have to ask yourself, what do I need to do? How long do I need to wait?

And so you have all these constraints, and so you have to have state. So this pattern is useful. I can't into the details of it some more because it's going to be a different talk and I think there's a whole different talk on sagas and how you can use sagas to work with evolving or changing requirements.

We said that, okay, events and messages are important, and we need to identify what events or messages are involved in this business process. So how do we go about that? And that's where this, this technique called EventStorming, Alberto Brandolini came up with it several years ago, and it's a fantastic collaborative technique. The way it works is, you just put a long sheet of paper on the walls literally, and then you collaborate with your domain experts. The thing that makes this work is you have to have the right people in the room.

And so you bring your domain experts, your architects, whoever is a key stakeholder of that process, of that system, you bring that person into the room. And then you start with putting up events. You talk to them and as a first step, you put whatever events that you think are part of the process, and you put them on the wall. And then you have conversations, and as you have conversations, then you're going to identify the constraints.

Your goal here is to try to find out as much information about the domain, about the constraints, about the pain points, and try to model that in a visual collaborative way. And when I first did this, it seemed very chaotic at first, because you have business people in the room trying to wonder, what am I even doing here? You guys are the programmers and architects, why am I here?

But then, once they start putting up stuff on the wall, you can use this process to to get discovery on an existing system as well. What I saw was, the people like started adding flows and how things work in terms of events. And then the business manager, he was like, "In this scenario, we shouldn't be doing whatever the action that the programmer said the software was doing." And the programmer was like, "No, no, that's how the software behaves." He was like, "Well, it shouldn't behave like that."

Well, that's the kind of conversations that you want to have. The sticky notes are cheap and writing code is expensive. And as an example, in a previous place where I worked, we tried to automate this process to it easier for this person. And there was a lot of manual work and a lot of emails that come and we had to streamline this process. One developer was assigned and there was a guy in New York who did the UX design and whatever.

So it took a month and we came up with the software, and then gave it to the lady who's supposed to work with it and she just said, "This is unusable. I can't use this." Unfortunately, nobody had taken the time to ask her whether this is usable or. She would have told us a long time ago and saved us like a whole month of development work. So, collaboration is super important and having all the right people in the room when you're making these decisions is important.

Again, sticky notes are cheap, you can throw them away, but writing code in design time, it takes a lot of costs. If we were to take EventStorming as an example and try to apply to the example that we were trying to do. We would first try to in the wall, try to identify all of the events that are part of this process. Aircraft type has changed is the event and we might need to know that the booked flight was changed because we want to try to get a new booking.

So whenever that happens, we want to publish an event saying that that thing has changed. So if a customer is not happy and cancels it, you want to have an event for that. So you try to identify all of the events that happened in this process. Sometimes it's easy and you can tell like, oh, okay, these events might belong in the flight-planning context, and these events might belong in the booking context. So sometimes you can tell.

But either way you have all these events on a timeline from left to right and you do this as a first step. Once you have your events, you then ask yourself, okay, what triggers this event? Or more importantly, when this event occurred, what actions do we need to take? So then we might have commands. So then you start putting up commands next to your events. In this case, when the aircraft type was changed, might need to rebook. So that publishes an event.

And when that book flight was changed, we need to notify the customer and we might have to wait, I don't know, few days, whatever the rule is. And then publish events. The thing about like these commands is, because we know the commands can fail and we can ask ourselves, what do we need to do if we can't rebook the flight? That question is not something we, as architects or programmers can answer. That is something that the business knows or the domain expert knows.

So they are the ones with the constraints, but they're not... We have to ask the right questions and knowing that these commands can fail, will help us ask these constraints, questions, and try to model that in our code. So we come up with this. Now, once we have this model, writing code is much simpler. You have an event, you're going to have whatever, a handler that needs to get invoked when that event happens.

In this case, when the aircraft type was changed, we need to find all the relevant routes and stuff, and we need to rebook the flight. So we send a message to rebook the flight. Inside the rebooking thing, we look at the routes and come up with whatever rebooking is. And then we publish an advance saying, "This thing was rebooked." And and now we can have like the saga thing I talked about where you're going to have multiple messages.

You need to keep track of how much time passed and if the booking was canceled or whether the cancellation period elapsed. For that, you have a saga that implements and does whatever it needs to do. So writing code is much simpler once you know and model these things along with your domain experts.

But as we all know, naming things is hard and it's one of the hard, hard problems of computer science. When we named these events, we are so accustomed to crud type things. We tend to call customer was created. Customer was updated. Customer was deleted. If you just think back for a second, who deletes customers like, "You are deleted"? We don't do that. We might say, "The customer was deactivated," or whatever the right term is, but we don't delete customers.

This is where yes, naming is hard and it's much easier when somebody comes up with the name and you look at the name and go, "Oh yeah. That makes sense and that's a much better name," but coming up with names is hard. And one thing that I strive to do, I used to do before is, yes, we're using events and we're using the past tense to name these events. We want to say, "PDF document was generated."

So yes, it conforms to how events should be named, it's in the past tense. It's a thing of significance important has happened. But what is PDF document generated mean to the domain expert? That's just a pure technical term for us. That doesn't mean anything to the business domain experts. So it might be that the letter was shipped, or certified mail was sent, or something that has a very, very significant meaning in the domain.

So you want to try to capture those names and that language in your code. So yes, naming is hard and this is where, again, the collaboration and the communication that you have with your business people and the domain experts are important.

Let's go back and take a relook at the requirement. The requirement was, passenger gets notified with a new booking proposal. The word was new booking proposal and yet I had originally called it rebook flight. We're not rebooking flight, we are just dealing with proposals, we're trying to propose a booking.

Again, it wasn't, the booked flight was changed, it was that rebooking was proposed. So you take this knowledge that you learned from your domain experts and go and modify your existing models. And that is something that you're going to have to do. So these are things that you're going to learn every day and that's okay. And you need to take that knowledge and apply it towards your model.

That's how your code is going to use the same language that the domain users use. And you get all the benefits of domain-driven design of trying to write software that aligns with your business. So it doesn't happen right away. I think it was George Box who said, "All models are wrong, but some are useful." So when we first design something, it's going to be not perfect. It's not going to be correct even sometimes. And that's okay, that's completely okay.

We just need to take our knowledge of what we learn and try to apply to our models. So we need to have a very healthy obsession with language, and this is why. Because once you start using the language of the domain, then everybody can understand your code. And if you leave and another person comes in, and that's fine, they can still communicate with the domain experts.

So the thing that I used to do was I used to name my handlers as whatever the event name was, in this case, aircraft type was changed. I would call my a event handler, aircraft type was change handler. Well, handler is just an implementation detail, you don't need that. And aircraft type was changed, that doesn't tell you anything about what's going on in the handler. So take a look at what your code is actually doing when that event has been received and call it the appropriate name.

In this case, that handler was trying to propose a new rebooking. Yeah, you can have sometimes long class names, but it's readable, it's much more understandable. Ditch the handler, but use the right domain language in your class names, in your handler code, everywhere. The same thing with the saga name, it wasn't a booking change policy, that saga was clearly dealing with just the grace period. What should I do if the customer doesn't cancel within a certain period of time.

Give your handlers and sagas proper names. Questioning yourself, is this right? Or like in your code reviews and peer reviews that you do, check for language and do these things. The other thing is messages are immutable, and when you use some things like ReSharper is going to generate properties with gates and sets. If messages are immutable, they don't change. You can't change an event. These are schemas published by one bounded context. So the other bounded context that receives it, it can't change it, so why should we have setters when we try to describe these schema messages? So you don't need setters, so you can get rid of them.

Also look for some concepts in your domain that are immutable, for example... It's a different example, but like maybe you're dealing with accounting and that's your domain. And in this accounting, you can only add stuff, you can't like go and update it. If that's the thing in your domain, don't let your code go and make it updatable. Make that domain decision, whatever that was immutable, the business domain experts said, "No, you cannot do this." Take that concept and then make your code in such a way that you can change that aspect inside your code.

One of the other important things about domain-driven design is this whole notion of being aligned with the business. Let's say, if want to modify this requirement and say that we don't want to really send notification to every economy class passenger, we only want to do this for platinum or first class passengers because when an aircraft type has changed, that's who it matters most. Because some people based on the aircraft type might lose flat business seats and go to angle business seats, and they might've paid a lot of money.

So we want to make sure we keep them happy, so we don't want to do this for everybody. Say you have a requirement like that. Now you're in sort of a little dilemma because you have the booking context and it's trying to work with the aircraft type was changed, but it needs data from the loyalty context, which knows whether the customer is preferred or platinum. The booking context doesn't have that data.

So how does the booking context go and get those data from loyalty? In order to fulfill this business requirement, we need to make sure we get this data. And once we get the loyalty status, then this booking thing can make a decision on whether needs to send notification or so on. The trouble with this is, yes, you can call rest calls or you can have synchronous communication. But what happens here is if whatever reason, loyalty context isn't available, you are stuck. You can't proceed.

You have resources that are stuck in waiting in the booking context that cannot make decisions unless you have the data. So how do you get rid of this dependency? Because this is the thing that is going to prevent you from being reliable and scalable. Temporal coupling is where you have a dependency on time where one service or one component cannot complete its operation until the other party's done with the work.

So in order to get rid of this temporal coupling, what you can do is you can use events, and you have the two contexts, the loyalty. The loyalty context can publish events whenever a customer was like promoted to gold or platinum. Now booking contexts can simply receive these events, and when it's receiving the events can store it into its own database of like, this customer is gold or this customer is platinum.

Now when the flight planning context is publishing this aircraft type has changed event, then for the proposing rebooking component, it can simply look at the data that it has to make that decision. So it doesn't have to go back to the loyalty. Now, the advantage with this model is that flight planning, and loyalty, and booking, they can all be scaled differently and they don't have to be up all the time to make these decisions.

However, the question is, what if this customer was promoted to gold event happened and inside the promotion information, we have that customer? But maybe the customer was like, I don't know, depromoted or lost the status and in this context you have them as platinum customers. What happens when there's this data stillness? And so we can answer that question, but we can ask the domain experts, how do we want to handle that case?

And it might be okay for a day or so and that might be completely acceptable with the business. But we as programmers, and architects, and designers can make that choice. However, by making this explicit in our design, we can ask the right questions and therefore we can choose the right answers. A lot of the times when we have like race conditions or requirements that look like race conditions, it really means that there is something in the domain that we haven't really teased out.

There is a policy or requirement, and we just haven't had the right answers. So we just have to keep digging for those information, and this sort of design makes that very, very explicit.

In this model, deployments become easier. When you have like a version 1.0 and you want to upgrade it to a version, 1.1, you don't even have to stop it. You could just bring up a new module and see how this works. If everything works, you can stop the other service or other component. But this also gives you a nice way where if the business wants to say like, "Okay, we want to try out like a new policy. We want to try this only for platinum customers or something where the behavior is different."

You could try it and let business know how things are working. If that's how they want to proceed, then they can stop the old behavior. So you can have two behaviors running at the same time, and evaluate, and how things go, and take decisions. So you are giving more flexibility to the business to do things like this. Of course, when you can always stop once the business is ready or once you're happy with your deployment, you can stop it in a one, but we all know that sometimes deployments don't go so well.

What happens if this fails? Now, the good thing with working with events and messages is that when this message goes to your second version, 1.1 and it fails, it isn't lost,. It's transferred to this error queue. What happens is now you can take a look and see why it failed. This notion, a lot of the queuing systems have this ability to poison messages, because you can have like some kind of transient error handling built in where for some operations like database, deadlocks or somethings, the exception will tell you, "Hey, please retry this operation."

In those cases, a temporary or a transient retry, a quick retry would work. But in some cases, it doesn't matter if you have like an old reference exception or something in your code. If it doesn't work the fifth time, it's not going to work the 100th times. Queuing mechanisms have this way, so you're not trying to DOS your system, so they take that message and they poison it, so, that message gets moved to the error queue.

Now you can debug and then figure out, and in the meanwhile, you can stop this bad end point and all of the messages will flow to your original end point. And then you can even take the messages that are in this error queue and play it back to the original end points, so all of your stuff gets processed. This sort of thing gives you reliability and also scalability, because now if you have a lot of load, and if you want to bring up five instances, you can do that.

In a system like this, monitoring becomes very important. When you have broken down your system into small pieces, it's not like where you had this big monolith where when something fails, everything is going to stop, everybody's going to know from the database admins to everyone. That was like, I suppose one good thing of having a monolith is where you know when things failed immediately.

But in a system like this where you've taken the time to design small parts, you can have a really small part failing where everything else is working, so messages might be getting piled up in this queue. So if you're not looking, you don't want to get a call from a customer and says like, "Hey, what happened to this thing?" Or you might have an SLA where you're supposed to fulfill whatever the operation is within a certain time. So monitoring becomes super, super important.

And you can look out for different metrics like queue length, how much time are you taking to process each message. There's a lot of things that you can look out for that you need to monitor. If you want to take away a few things from the stock, first and foremost, I think the communication, the collaboration that you have with the domain experts is key, because that's where all of the good stuff comes in, and that's where we want to build the right thing. We just don't want to build any software, but we want to build the right thing.

By event storming and having this sort of like collaborative way of talking to people, we can ensure that. And also recognizing that our models are not perfect, and that's okay. We need to just evolve. We need to take the understanding from the domain and apply it in, some of the information is going to be like a hallway conversation, and that's okay. And you are going to get some information from that.

You might find out that the event that you've called was not a right name. And so you take that information and you go refactor. So it's all about refactoring with an obsession for domain language. Again, the key here is, our whole idea here is we want to try and model the behavior of the business, and that's where all the complexity lies. So if by having conversations and we model this behavior, we're in a much better shape.

And again, lastly, to communicate... Sorry. Oh my goodness. Sorry. Okay. There we go. Use events as a way to communicate between bounded context. Messaging as a technology gives you a lot of this freedom and autonomy. And so if you are writing really small services that are autonomous, that can scale on its own, to me, you are in the land of microservices. That's why I feel like when you combine the discipline of domain-driven design and then use the technology like messaging to communicate between bounded contexts, you naturally land up in a land of microservices.

So if you wanted to learn more about DDD, there's Eric Evans' book, The blue Book. And if you start, I suggest you start with part four, strategic design. I think Eric himself mentioned that if he were to rewrite the book, I think he would have started with part four, so it might be a good idea to start with part four. And there are two DDD very, very specific conferences. One's in Denver, in September and the other one is in Europe, in Amsterdam.

That one, I think there are like event sourcing days, beginning DDD or foundation days and so on. Both these conferences are fantastic places to go learn more about DDD. And also there's an ebook that's available for free published by DDD Europe and it's on leanpub.com/ddd_first_15_years. It's been 15 years since Eric wrote the DDD book. These are all great resources.

Thank you so much. I hope I was able to share some information about why I like DDD and event-driven architecture. Thank you.

PracticalDDD: BoundedContexts + Events => Microservices

🔗Transcription