3 ms·

Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always

by pravus 3y ago

Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always possible to front-load that into a simple schema in your transports and each component needs to be correct in its own domain.

KronisLV 3y ago
> Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. While it certainly isn't always possible, I've definitely seen it be aggregated in a single place in monolithic codebases that focused on CRUD. Essentially, it was structured like so: +--------------+ +------------------------+ +-------------+ |Resource (API)|---|Service (business logic)|---|DB Repository| +--------------+ +------------------------- +-------------+ | \ +-----------------------+ \ +-----------------+ |Validator (validations)| \|REST clients etc.| +-----------------------+ +-----------------+ The Resources were typically just API endpoints (HTTP), that passed data onwards to Services. Those could then call upon other services or service requests on their own: store/persist data with Repositories, deal with scheduled processes, or pass data on to other systems through REST clients etc. Before Services did any of those, they reached out to a Validator to make sure that the data matches the business rules and constraints. Sometimes there was additional validation context passed in (essentially a map and some enums), sometimes there were certain constraints that an entity needed to always follow within the context of the business and so on. In practice, it was good because you could see all of the constraints in one place, that an entity has to match before it can be persisted in the DB, or passed onwards to another system. But then again, that's not always viable in more modern architectures. Of course, it wasn't the most traditional approach to MVC either, even if those concepts translate pretty well to it.

by pravus 3y ago

KronisLV 3y ago

> Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. While it certainly isn't always possible, I've definitely seen it be aggregated in a single place in monolithic codebases that focused on CRUD. Essentially, it was structured like so: +--------------+ +------------------------+ +-------------+ |Resource (API)|---|Service (business logic)|---|DB Repository| +--------------+ +------------------------- +-------------+ | \ +-----------------------+ \ +-----------------+ |Validator (validations)| \|REST clients etc.| +-----------------------+ +-----------------+ The Resources were typically just API endpoints (HTTP), that passed data onwards to Services. Those could then call upon other services or service requests on their own: store/persist data with Repositories, deal with scheduled processes, or pass data on to other systems through REST clients etc. Before Services did any of those, they reached out to a Validator to make sure that the data matches the business rules and constraints. Sometimes there was additional validation context passed in (essentially a map and some enums), sometimes there were certain constraints that an entity needed to always follow within the context of the business and so on. In practice, it was good because you could see all of the constraints in one place, that an entity has to match before it can be persisted in the DB, or passed onwards to another system. But then again, that's not always viable in more modern architectures. Of course, it wasn't the most traditional approach to MVC either, even if those concepts translate pretty well to it.