0

I'm studying CQRS and FluentValidations and I found myself wondering where would be the best place to validate information within the database: directly in the handlers responsible for orchestrating the requests or within the validations even before reaching the handlers?

I have a business rule that involves the identity of an entity, where in the database this attribute is a unique key, that is, this document can only be linked to a single record. If the document already exists in the database and there is an attempt to insert it again, the database will return an error of contraint violated and I don't want that to happen, I want to handle as few exceptions as possible coming directly from the database.

So, I want to create a rule that validates at the time of insertion if the document in question is already linked to another entity and if it is already I will return an error stating that it is already linked to a record.

I managed to do this validation both ways. The first way was to validate this document directly in the handler, where I research if it is already linked to a record in the database, if it is, I return the error. The second way was to add a dependency injection inside the class that does the validations using FluentValidation.

So, my question is, what is the recommended practice for this situation?

Silas Enrique
  • 5
  • 1

2 Answers2

3

In any application you can split up validation in two groups: superficial validation and domain validation.

Superficial validation

Superficial validation is validation to check if all values are in the right form. This is probably the first thing you do. For example, you want to validate if a string is not empty or that a field falls in a range of predefined values.
A good way to do this is to parse the primitive values to classes which represent the constrains of the field. For example, a string value that cant be empty should be parsed to a Text class, which never can have a empty value.
With this approach you'll never have to do this superficial validation anywhere else in your app because you only work with the Text class which never can be empty.

Domain validation

Domain validation is about business rules. This kind of validation is performed in the application or domain layer of your app. A domain model is responsible to protect his own state. So the most of the validation goes in a domain model. If you need to validate state over multiple domain models, you would check this in the application layer. This is where your command handlers should be.

In your example this is the place where you would check if the document is linked to a single record. In other words, this kind of validation is done in your command handlers.

L01NL
  • 1,753
  • 1
  • 13
  • 17
0

It's a good idea to use unique and foreign-key constraints in your database as the last line of defence against data corruption.

But having validation in both places makes things more complex, harder to test, and for others to understand. Reducing the complexity should be every developer's goal.

I like this quote: enter image description here https://twitter.com/BrentO/status/1227589450814894080

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • the intention is that the entire deal is validated well before it arrives in the database. In the database, I just put some very basic rules as an exception – Silas Enrique Sep 18 '22 at 23:20
  • I would do the validation in the handler, I think that code that changes together, should be placed together. So, that all is in one place, there's no need to add complexity by doing dependency injection of your validation rules. – Tore Nestenius Sep 19 '22 at 06:57