The last elements we will be using in the design-level session, is policy. As we learned, actions in the system are represented by commands. Users can execute actions by sending commands. When a command is processed, the system changes its state and emit events. This is the initial reaction of the system on the users action. But, when we publish events, we also let know to other elements of our domain model, about something that happened, but which were previously unaware of the command being executed. This is very useful in order not to perform all work linked to a certain action to be executed at once. Ideally, we should limit the amount of work we do to process a command by the absolute minimum. Technically, such atomic operation can be represented as one transaction. It might very well be that some other operations also need to executed as the result of the domain model state transition, but we don’t need to wrap these actions in one transaction and force the user to wait until all such work is done. This is exactly where we need policies. Policies subscribe to domain events and when a policy receives some domain events it is interested in, it will check the event content and potentially send another command to the system, to complement the work. There might be numerous of policies reacting to the same event type, doing all kind of post-processing in asynchronous fashion, whilst the user gets control back after the original command has been executed.

We can express policy on our modeling space like this:

Looking at such a model, we can transcribe like this: when the owner of a classified ad marks it as "sold," the system should also deactivate this ad.

As you can see, a policy can react to domain events and issue commands, based on certain conditions. Such behavior is called reactive behavior and systems, which is actively using this pattern can be referred to as a reactive system.