Let's now talk about tactical design. So we're shifting from the broad brush strokes, the brush strokes with a lot of paint coverage on one single brush stroke, to tactical design, which is more like the detailed fine brush strokes that are working on small areas of detail. Here you see generally represented are components such as a process manager or a saga. We won't go into this right now, talk about this a bit later. But there is an imperative, a command being sent in to a service, a tactical domain service known as the risk assessor, and assess risk command arrives at the risk assessor. The risk assessor assesses the risk as it is being commanded to do. And as a result of some data from machine learning, which this machine learning algorithm is known as a policy or a set of business rules or constraints that provide direction on how certain information will be produced or the kinds of business rules around that. And as a result of applying the machine learning algorithm and consuming data based on that, it can, the risk assessor can generate an assessment result, and we've already seen the assessment result being used, which then emits a risk-assessed domain event. And on either side of this, we see that the process is taking place from the left and continues to the right after this area of work is accomplished through these tactical components. So what are some of these components? One very important kind of tactical component is known as a module and what you see here are different modules. Let's say that this folder or this module is representative of a bounded context within a monolithic system. So instead of having a separate microservice, a separate sort of software deployment for underwriting, we're simply putting it into a unique container, a unique module, and inside that module, we have other finer-grained modules. So we have areas of intake, processing, policy, and renewals. Now, this may be different parts of a model, for example. So, there is, let's say now that actually underwriting owns intake and underwriting owns processing or underwriting owns and underwriting owns policy, a kind of policy that it uses, and underwriting owns renewals. Or it could be that underwriting simply represents a monolithic container, and each of these are separate modules that are the separate bounded context. modules that are the separate bounded context. So it could be that intake is a separate context, processing is a context, policy is a context, and renewals is a context. Could be. So the granularity of modules can be determined by the team, but it is a way of organizing by clear naming. And by clear naming, we then know how to organize and separate the parts of the software that belong into each of the individual modules.