One question, an important question, is why use domain-driven design? Well, first of all, just to repeat myself a little bit, this is for solving complex business domain problems. There's a law in software that was understood and posited back in 1967, and this is known as Conway's Law. Conway's Law states that organizations which design systems, and as Mel Conway, the author of this, states in the broad sense used here. So in this paper that he wrote, I'm just interjecting a little context of my own here. In this paper that he wrote, he was not talking necessarily only about software systems. It could be hardware systems. It could be actually any kind of system. So that's why he says in the broad sense used here. But we can apply this to software systems. So again, organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. What does that mean? Well, notice that I have a dashed line that separates two organizational structures. The organizational structure on the left is very typical. This is where you have a relatively small group of leaders at the top of an organization hierarchy. And if you're working in a startup, this may be only two or three levels above most of the software developers. And if you're working in a very large organization, it could be 20 levels or somewhere between, let's say, 10 and 20 levels. And believe it or not, there are some companies that are so enormous that you can even have more than 20 levels of separation from the C-level executives to the point where you're actually interfacing with software developers. Now, you can imagine that with this kind of structure, communication becomes very, very complex. Communication is actually like playing what we call in the United States the telephone game, where you essentially have a group of, let's say, 10 individuals, and the first individual, the first person, whispers a short story to the person standing next to them, and the person standing next to them relays that message to the person standing next to them, and this relay goes to the 10th person. And by the time the message is relayed, it actually looks almost nothing like or sounds nothing like the original story, the original message that was first whispered. And this is essentially what happens with software. Leaders, executive leaders, have a vision. They have an initiative for strategic innovation, and they want something carried out. By the time the message actually trickles down through many levels, or even just a few levels down to the software team, there are so many translations that occur between there and filtering, and even our lack of detail and memory can affect that to the point where by the time it reaches them, it's so diluted, it's so filtered that the software developers don't actually have a clear idea of what was intended at the very top of the organization. On the other hand, notice the figure on the right-hand side. This is where you have both domain experts who have been given the job of carrying the vision forward. And these visionary, or at least domain experts, directly work with software developers to ensure that the message of the business, the left-hand side of the right-hand image and the three software developers to the right-hand side that are next to the computer, these are working actually on the same team. are working actually on the same team. Now, if you use this kind of hierarchical communication structure, it's really, as I explained, a very poor structure for software development. Communication is just very limited, and the individuals involved in the software same very large software model. And this very large software model becomes confused, tangled, coupled, you know, one class to many classes or one object to many objects and the model is just fractured and as you can see as you can see the individuals who are working around this may or may not really be working on teams they might work together or shift teams in you know know, in the middle of their work. They might be required to work on one thing this week and something entirely different the next week. And communication just does not flow carefully. This makes for some very, very poor software design and also software architecture. And even when we try to create a minute structure by breaking teams into very small units. Again, perhaps just one software developer or just a few. And these are using microservices as a means to decouple the development and make development autonomous, also what tends to happen is that these very, what I call tiny, tiny microservices, perhaps managing just one single small business concept, tend to get coupled together. And this just results in what we know as a big ball of mud, only, okay, now it's disconnected and distributed, but it's still a big ball of mud. And very similar to what you see here, we also call this the results of this communication structure and the software that it produces a big ball of mud. The difference is this is in one software deployment, whereas this many software deployments. Good communication structure where the business domain experts are working directly with a small, close-knit software development team with the technical experts who are developing the software, actually writing source code for the model, for the software model. These are working closely together, and it creates a good communication structure. As a result, as you can see, a model is created by this small group of individuals that has a very clear ubiquitous language, a very clear communication style that lends itself to being very accurate in the software model. software model, and it's bound by a context where the context has very exact, precise meanings. And this, as you can see represented here, does actually create for a very strong, a very good communication style. We would even go so far to say that this is not only communication, it's conversation, it's dialogue between all of the individuals on the team. Here's another look at the effects of Conway's Law on organizations. These two sides of the figure here represent communication structures through teams. On the left-hand side, there are three teams, the left-hand side, there are three teams, and each of the teams specialize in a particular area of technology. You can see that the top team thrives and is expert in user interface. The middle team is very strong in back-end, what's called back-end developers. And finally, we have DBAs or database developers, database administrators, and all of these are separated, which, again, fractures the communication structure. On the other hand, if we look at the right-hand side figure, what we're doing is assembling what are known as cross-functional teams. Cross-functional teams mean that you put one or more of the individuals who specialize in various areas of technology onto the same team. Now, sometimes we have what are called full-stack developers, and full-stack developers are a rare breed, someone who is really, truly very good at user interface design and development and back-end design and development and database development or strong with the API provided by databases. And so we actually tend to benefit from having more of a cross-functional team rather than trying to load up a single team with what are called full-stack developers. But that's really up to the organization. The point is that we want communication to be cohesive across these functions, across these technical functions and business functions rather than distributed across different teams. And when we have this kind of arrangement, we have a big ball of mud, and again, this just continues to lend itself to the big ball of mud because actually everybody having a different specialty has a different mental model, a different way of thinking about the structure that is actually available if you were to have domain experts and a cross-functional team working together. And as you can see, the coupling, even the usage coupling of broker agents, for example. This is in the field of insurance. Broker agents, front office workers, back office workers, and risk assessors, they're all just referencing different parts and using different parts of the software rather than having specialty areas of the software to work on directly. On the other hand, with the good communication structure that involves not only domain experts with technical experts, but also technical experts with cross-functional capabilities on a single team. This strengthens the communication structure and therefore results in a good communication structure, yes, resulting in good communication, and we have the tendency to develop much better modularized software because the conversations that we have are focused into particular areas. So each of these three areas that you see on the left with three different teams, they're specializing in different parts of the software, such as at the top one, the top team is working on claims. And you can see that there is a claims model on the right-hand side in the monolithic container. And you can see that underwriting is the model at the bottom, and this is with the team at the bottom on the left-hand side, and underwriting is the model in the upper right of the monolithic container, and so on. So each of these teams are focused in a very specialized area of the business. This makes for good communication structure and a good result.