Let's talk about strategic design of domain-driven design. Strategic design is where we are mostly focused on software strategy. This is sort of the big picture. If you were to think about painting a home, a house, whether it's interior or exterior, you need two kinds of brushes and two kinds of brush strokes, if you will. You need the brush strokes that are very broad, that cover a lot of ground, a lot of the area of the house on which you're working, and we can liken that to strategic design. And we'll talk in a few moments about tactical design, but the point of tactical design is that these are like the very small, very focused, narrow brush strokes, the thin brush strokes that are working on the detail. So let's first talk about the broad brush strokes and what we get from those. So this is strategic design. And as I've already introduced, one of the, basically, the cornerstone of domain-driven design is the bounded context. This is a place where a model and all of the model elements have relevance. They have a very carefully defined definition, and the definition is very likely different in this context for any of the terms used. Let's say that we have the term policy. What is a policy in this context? Well, it has a very direct sort of reference to the other policy in a different context, but have quite a different meaning than policy does in the originating context. So this is one of the main uses of the bounded context. And as you can see, strategic design includes team language context. So the bounded context is a context for language, a ubiquitous language. And as you can see, this team of five are discussing different concepts. We're just using, I'm just using single letters here to represent concepts. And let's say that the team member on the far left is thinking about and discussing the concept A. And the team member next to that individual is thinking about and discussing the concept Y. is thinking about and discussing the concept why. And the person in the middle just has a question. What are we talking about here? The person to their right is thinking about and discussing the concept B. And finally, the person on the end sees these things working, A and B working more closely together, and they are then thinking about A, B together. What does this result in? Well, it's not meant to result in disagreement and argumentation, the ideas behind the bounded context and the single team that's working within the bounded context is to have dialogue to resolve these differences in the way that individuals think about the problem and a possible solution to harmonize those so that we blend the full ideas of the entire team, not necessarily through compromise, but simply through clarification. And now everybody on the team has a shared understanding of this mental model. That leads to their ability to create a software model based on the language that they develop. Now, the pale yellow or the light yellow rectangles inside this bounded context reflect the ubiquitous language. The ubiquitous language is, in essence, being spoken into those model elements. So the model elements have names from the ubiquitous language, from the ubiquitous language. And any behaviors or actions related to the ubiquitous language are also reflected on the model elements. And the model elements have state or data associated with them. And the names of the data types, all of the data types are generally related to the ubiquitous language and the the state of the ubiquitous language also is understandable and used by the behavior that is part of the model element. So all of these things play together, but they're really focused on just one aspect of the business problem. So now you can see an example of this insurance industry kind of set of software models. These are actually three different bounded contexts, and perhaps you're learning about or already know about insurance underwriting and insurance risk and the rates that are applicable based on a certain kind of risk that is associated with insuring someone or insuring their property, such as a home or an automobile, a car. And notice that these three bounded contexts work together, but the idea is that they are also loosely coupled. There is not strong coupling like we saw in the big ball of mud where everything is convoluted, very tightly coupled, many things to many other things, and it really ends up being a very fractured environment, a very weak and volatile environment to work in where it's difficult to make changes to the software because every time that you change one area of the software, problems tend to pop up in completely what you think are unrelated, completely unrelated areas of the software. In this case, each team, there would be in this case three different teams, a team for underwriting, a team for risk assessment, and a team for rate calculations. and a team for rate calculations. All three of those teams are focused on their area and their area of expertise, their bounded context, their individual ubiquitous language, and therefore each one of the teams can work autonomously, independently, Each one of the teams can work autonomously, independently, but they're not trying to solve the problems with tiny, tiny microservices. They're generally using larger models that cover the entire area of expertise, such as risk and rate calculations and so forth. such as risk and rate calculations and so forth. So language context is very important with domain-driven design. If you look inside a software, an enterprise software environment, note that there are all kinds of systems. And I've shown here that there are generally many legacy systems that tend to be the big ball mud. Those are the darker color, muddy-looking system scopes that you see there numbered as two. as two. We also have some cleaner system scope areas of the software of the enterprise that are labeled two, and those are shown scopes and they're they they integrate with some of the legacy scopes some of the big ball mud scopes but they themselves are designed for a clean sort of loose coupling almost disconnect or very light touch connection to system scopes that are outside of their own system. Finally, you see the third and fourth areas of the enterprise, and the third area is where we are now focused. So we have a software initiative that's known as a problem space domain, or as I have here, a problem space scope. a rather coarse-grained set of problems, and it involves more than one bounded context or one single legacy system, and therefore we separate this and say, okay, to our, within our enterprise, this is a very specific problem space. We're not trying to use the entire enterprise. We're only thinking about the areas of the enterprise that we are developing new and that we have to integrate with. And that's why the context, the bounded context, number four inside the problem space scope, these are integrating with the Big Ball Mud legacy systems, but again, in a very loosely coupled way. And you'll notice that even one of those contexts is integrating with a clean system scope level there at the bottom. a clean system scope level there at the bottom. So think now, just remember this idea, this concept of a problem space domain.