When we are building applications, it's quite common to find ourselves writing tons of validations on the retrieved input before using the provided information in the system.

Common validations applied to the retrieved data include the following:

• Verification for non-null values
• Specific text formats, such as emails
• Checks to validate string lengths
• The maximum quantity of decimals allowed in numbers

There are many mechanisms available for implementing this kind of validation within our code. The most popular of these are based on third-party libraries that rely on annotations that can be extended using regular expressions for specific scenarios. There is even a specification that is part of the platform that can be used to validate class fields called Bean Validation. This is currently part of the Java Specification Request (JSR) 380 (http://beanvalidation.org/).

While it is essential to have all these validations when users or external systems provide the data, there is no need to keep performing these checks when the information is read from the database and returned to the user. Furthermore, in some cases, such as event sourcing, once the data is retrieved, some commands are executed, events are created, and at the end, the information is persisted.

In these scenarios, it is apparent that the processes to persist and read information are different, and they need separate paths in order to accomplish their goals.

The following diagram shows how an application uses different paths to persist and retrieve data:

From the preceding diagram, we can quickly note how much processing is avoided because it is absolutely unnecessary. Furthermore, the domain models used to query and process the information are often different because they are tailored to accomplish different goals.