Validations across micro-services
Example: amazon selling for other companies
Validations are often more complex than you think
- We want to stop doing business with a certain supplier, however in this case we would probably not want to remove the agreement physically, but just mark it as discontinued.
- Once we stop doing business we want to clear our databases to adhere to privacy requirements, so we actually do want to physically remove the agreement. However, in this case we cannot remove the products, as this would remove the order information too, which our customers might need.
- The seller might decide during the negotiations he doesn't want to actually sell his products via amazon.com. In this case, we want to remove both the agreement and the products.
- High-level, there is a business process going on. This business process defines the intent of the user: what does he want to achieve
- Based on the high-level business process, there are various actions we want to perform, which might have a different effect on the system. These consequences can then be handled by other parts of the system. For example, the action is to stop the negotiations, the consequence is to remove the products of that seller.
Process driven systems to the rescue
- The running business process provides the high-level context. Determining which step we need to do at each stage of the process. Whenever we need user-interaction, a user task is started.
- The concepts from DDD, the Business methods on our Aggregates, provide the various actions we can perform. By definition of DDD, these business methods result into Domain Events, which we can employ to determine the consequences of our actions. The process is often the component responsible for translating Domain Events into new Commands.
Let's see this in practice!
The product service in turn, listens for these events. We DESIGN the system that way, because we KNOW that THESE events are relevant to this service because it enacts actions to enforce consequences. These are the rules of the business. Technically, we can of course solve this using something like JMS or Kafka to ensure technical coupling. In this setup, the agreement service is unaware of who is listening to these events. Moreover, the context we added to these events allows the product service to take appropriate action:
- In case of a "Negotiation Cancelled", we just remove all products of that supplier
- In case of a " Agreement Discontinued", we disconnect them from the agreement, mark them as not for sale anymore, but still provide our users with the needed information.
Note: there is an extra bonus to using these concrete events instead of the more generic Create/Update/Delete actions. By using these events, and as our process engine stories the history of the processes executed, we can understand afterwards why certain actions were performed. This can often be beneficial for the business to understand and improve their own processes.
Note: just to be completely clear, I'm not advocating the usage of business processes and DDD for any system. These types of architectures can be quite complex, and are optimized to tackle and cope with complex use-cases. Simple systems, for example an address book for your Soccer-club probably wouldn't benefit much from these kinds of architectures. You can of course build a simple system win this way, but sometimes the benefits don't outweigh e.g. the startup costs. For these kinds of use-cases, data-entry style applications are perfectly fine to use.