Now, as we zoom in on that problem space domain that we were just looking at, so we have our enterprise scope, and then we jump down without looking at the level two, we now are just focused in the problem space, notice that the five different bounded contexts, which are the number four level scope that we saw in smaller form in the previous slide, these are very specialty areas of the problem space. This is where we are solving a problem around policies of insurance. So notice that the underwriting bounded context uses or is used by, I should say, the claims context. And the renewals context uses something from the underwriting context. And the risk context uses something from the intake context. So intake, meaning that this is where those who are applying for insurance fill in applications, and that is the intake, and then those flow into risk, and risk, which flows or the work done by the risk flows into rate, which we're not showing here. I'm not showing here. But you can see that these are five different teams, five different areas of expertise, and five different areas where domain experts and technical experts are working together as a single team. This is known as a problem space domain, and the individual bounded contexts that are inside of this problem space domain, along with any other parts that they are integrating with, which are not seen here, but perhaps legacy or other clean, newer system scopes, these are known as subdomains. So at the problem space level, we would actually be thinking more about the problem space domain and subdomains, a solution space, then these subdomains, underwriting, intake, risk, claims, renewals, each of those are now sort of transitioning into a solution space where they become bounded contexts. There are different kinds of subdomains with domain-driven design. As you see here, there is the core domain, which is a kind of subdomain, supporting subdomain, and generic subdomain. Domain-driven design, as I said earlier, is meant for solving complex business problems with software. The core domain is the focus of why you would be using domain-driven design in the first place. The core domain tends to be complex. It's an area that doesn't even have a broad area of expertise yet because there may not be any expertise. It may be so novel, so new, that there is little knowledge about what we're working in, and we have to constantly probe to understand what is this core domain about? How are we going to solve this problem using the vision of some new innovative software techniques and model? The supporting subdomain is software that does not exist previous to this, and it is meant to support the core domain, but it may not be complex, or it's probably more like complicated or even clear, but this is being developed because you can't go out and purchase a supporting subdomain. There is no support for this, yet you do not want to invest in the supporting subdomain at the same degree that you do the core domain. The core domain is where the gold is, and that's why I've used the gold color, whereas the supporting subdomain is sort of like a silver. If you're thinking about Olympic medals, for example, you know, the gold medal is at the upper left. The silver medal is sort of, you know, below, less valuable, or at the mid-level. And then the generic subdomain is basically areas of software that you can generally purchase or download from the Internet. And the point of these generic subdomains is they're generally complex, but they're areas that we do not want to specialize in as a business. They're not gold. They're simply the bronze. We can go out and we can purchase software. We can download software from open source or something like that and come up with some solutions that are very necessary but not germane, but not germane, not extremely important to the business in terms of how they will differentiate themselves. So, for example, you can imagine an ERP, Enterprise Resource Planning software, which includes accounting and HR and purchasing and many different areas for running a large business, very necessary, but we simply want to spend, you know, a capital sort of investment or expenditure in order to obtain software that performs the generic kinds of solutions for us or provides generic solutions for us. Here's an example of subdomains, different subdomains, and the level of investment that we want to make. So those with the parenthetical core at the center, such as underwriting, renewals, risk, and rate, those are where we are investing now. And it can be that over time, the investment decreases. Perhaps underwriting is one of the first areas of expertise that's being solved very rapidly, whereas risk and rate will have some ongoing development in order to continue to tune the software model and explore new areas in order to ensure that we have the best risk assessment and that we have the best rate calculations. The supporting subdomain domains are, for example, intake, claims, policyholder, and billing. Well, I roll back on that one. Billing is generic. But the point is that intake is supporting to underwriting, and it's supporting to risk. Claims is supporting because we're not necessarily putting a lot of investment into claims right now, although it could be that in the future we want to put more investment into claims and it could become a core domain. Policyholder is supporting because it's something that we need. In fact, it could even be that we could go out and purchase some kind of a policyholder solution from a company, and that could become actually a generic subdomain as billing is. Because, look, billing is very commonly a kind of product, and it might even be pushing into the area of commodity, where there are so many billing solutions that we can take our pick of, you know, basically select our favorite or the one that is most feature rich or has the best support and the best reputation among all billing products that are out there. Perhaps they're even managed services in the cloud, very reliable, always up, never have to worry about the billing system being unavailable. So we can measure the value of this by the ease of incorporating it into our system, let's say through cloud subscription, whereas with the core domains such as risk and rate, we're going to have to spend considerable time with a team of domain experts and technical experts in each one of these core areas so that we can focus on very careful modeling exploration experimentation whatever is needed to understand the depths of the language and model being designed and implemented in those areas