The title of my talk is Domain-Driven Design, MBA Full-Cycle Architecture. So this is for the MBA program. I'm going to explain, first of all, what is domain-driven design? Second of all, why use domain-driven design? Second of all, why use domain-driven design? And then I get into the strategic and tactical patterns, strategic first and then tactical patterns second, and then finish off with some software architecture, the patterns that support domain-driven design and supplement its use. So let's get started. What is domain-driven design. So rather than spelling out domain-driven design everywhere, you'll see that I use DDD as a short name, an abbreviation. an abbreviation. So DDD is basically a way of thinking about software model design. This is where you have a team, and the team is focused on knowledge crunching with the help of technical and domain experts to solve a complex business problem in software. Now, when I say domain expert, using the word domain from domain-driven design, what I refer to is what's known as a sphere of knowledge. You might think of a domain as like a kingdom or some kind of ownership, something like that, but a domain, according to domain-driven design, is a sphere of knowledge. So you can imagine that you're doing a lot of knowledge crunching. We're taking in as much knowledge as we can that's available to us from the business through domain experts and then working together as business and technical people using, I would say, technical people using, I would say, what I would call three architectures, business architecture, social architecture, and technical architecture to work together to solve complex business problems with software. And I want to focus on the word complex because domain-driven design is really meant for modeling in a complex problem situation. It is not meant for general purpose solutions to relatively simple, obvious, clear kinds of software development. And one of the main focuses of domain-driven design is that it is contextual, meaning, as you can see there, we have an image or a figure that says bounded context and ubiquitous language. Well, this bounded context is a context in which a language is developed, and the language is developed using spoken language, let's say English or Portuguese, Brazilian Portuguese, or any human language, but we're constraining that language to what is necessary to support the software model that's being developed. And as we speak as a team, as you see there are the five individuals represented, not a very large team, might be a little bigger than this, might even be a little smaller than this, but the point is that this team speaks to one another and describes the business problem that they have and takes in the knowledge from the business people or domain experts, and together they develop a language. This is known in domain-driven design as a ubiquitous language. Now, the word ubiquitous means ubiquitous within this context, and it's a relatively small context. This is not generally a very large body of software that's being developed, but it's as large as it needs to be to solve the software problem at hand, develop software to solve this business domain problem. And as this context is the home of the business language, it ensures that the definition of the language, of the language parts of the model that's being developed are constrained and defined exactly as they are meant to be used in this software model, exactly what they mean in this very specific context. So we don't expect the language to be throughout the entire business, the entire enterprise or whatever business that you happen to be in. The language is only ubiquitous within this context with the team and the software and any documentation or architecture drawings or anything that you're working on, the language is ubiquitous in that way. And domain-driven design includes strategic-grained software modeling decisions. So we'll look into those.