Reglas de Validación y Reglas de negocio

Es importante que se pueda realizar la diferenciación entre ambas. Es muy fácil confundirlas y terminar realizando reglas de validación en vez de reglas de negocio.
Las reglas de validación son partes reusables de lógica, que llevan a cabo dicha validación sobre una entidad; misma que puede variar entre validación de integridad hasta validación de estado y cuya meta es realizar una validación sobre la entidad antes que alguna acción sea realizada con esta entidad.
Podemos identificar entonces las siguientes validaciones:
Validación de integridad: Se lleva a cabo sobre los datos que un usuario introduce al sistema, para asegurarnos que no se lleve a cabo ninguna acción con esos datos a menos que cumplan con los requerimientos. Ejemplo: El nombre no debe ser nulo, el nombre no debe ser vacio, debe ser al menos 10 caracteres de longitud y no debe contener caracteres especiales.
Validación de negocios: Es muy similar a una regla de negocios, pero se debe clasificar como validación. Por lo general es la validación del estado de una entidad.
Por ejemplo: Si la clasificación del cliente es preferencia, el monto total de su crédito no debe exceder los 15,000 pesos.

Porque sería estatus?
Si el cliente tratara de realizar una compra a crédito por un monto mayor, esta sería invalida, por que el estatus de la compra seria invalida.
Las Reglas de negocio son partes reusables de lógica que realizan acciones sobre una entidad, basándose en ciertas condiciones que son evaluadas contra la entidad en sí. Simplemente las reglas de negocio no realizan ninguna validación, en vez de eso, llevan a cabo acciones que son definidas en la regla.
Esta diferenciación es muy importante ya que en las reglas de negocio, las validaciones de datos y estados ya han sido realizadas, las reglas de negocio llevaran a cabo acciones sobre los datos, basándose en los datos y su estado. Las reglas de negocio no impiden que se lleven a cabo acciones, como salvar una orden de compra, eso lo hacen las validaciones.
Poder diferenciar estas piezas de código, nos permiten aplicar el patrón de desarrollo adecuado, y así poder aprovechar la reusabilidad.

Las reglas de negocio
Las reglas de negocio son en realidad la razón por la que se desarrolla un sistema. Por ejemplo podríamos poner "Aplicar una comisión del 3% si el cliente compra más de 200 pesos en la compra de x producto".
Los que nos dedicamos a programar incluimos estas reglas como parte de la lógica de la aplicación, a simple vista las reglas de negocio están inmersas en la lógica del negocio, por ese motivo es muy fácil que para el desarrollador sean instrucciones a codificar.
Son aquellas condiciones que ayudan a que el negocio tenga sentido, son las que le permiten al negocio ser competente. Son el secreto mejor guardado de cada organización.
Si revisamos lo que acostumbramos a hacer podemos identificar esas reglas en aquellas condiciones que solo nosotros podemos cambiar. Para que el sistema pueda atender una variante en la lógica actual, es necesario reprogramar dicha condición...eso es una responsabilidad muy grande. La programación tradicional esconde esas reglas como lógica al encapsular los métodos de las clases, en vez de exponerlas y permitir que la aplicación este lista o dispuesta a aceptar cambios sin la intervención del equipo de desarrollo.
Si existe en nuestro código algo que desde el principio está destinado a cambiar esas son las reglas del negocio, deben ser como el negocio en sí, dinámicas y adaptables. Las reglas de negocio deben ser visibles a todos los módulos que interactúen con ellas, las reglas de negocio deben ser expuestas y deben ser adaptables.
El éxito se logra cuando los usuarios son los que pueden crear, actualizar o modificar las reglas de negocio. De esta forma la aplicación es un consumidor de ellas a manera de servicio.
El problema estriba en que las personas tienden a ver las reglas de negocio desde la óptica de su propia formación, esto presenta un conjunto de aspectos que resulta demasiado variable al tratar de crear una interface que pueda ser utilizada por los usuarios y de esa forma crear un framework que sea genérico y reutilizable.
Además cada aplicación al ser construida contiene la lógica específica que operativamente puede soportar una organización, las tareas por lo general siguen esas reglas.
Esto resulta obvio y nos permite vislumbrar lo que ha estado ocurriendo cuando se desarrollan aplicaciones, incluso hoy en día. En estas tareas el código se concentra en manipular entidades, que físicamente representan facturas, órdenes de compra, etc.; documentos, formatos y piezas de información que por sí solas no aíslan como elementos independientes las reglas que los rigen. Debido a que el diseño se basa en estos documentos, es particularmente difícil identificar esas reglas, mas aun por que los arquitectos muchas veces no son expertos en la forma de operar la atarea en esa empresa en particular.
Las reglas del negocio residen en los usuarios que indiscriminadamente aplican sus criterios y toman decisiones sobre la marcha. Estos se conocen como requerimientos no explícitos. Las políticas están escritas en algún manual de operación de la empresa, y se han tergiversado con el paso del tiempo. Ese manual contiene requerimientos explícitos de las reglas del negocio.
El impacto de esta realidad en un sistema de computo es en relación al tamaño del mismo, donde una aplicación pequeña puede ser manipulada y controlada por los usuarios y las reglas de negocio podrían pasar desapercibidas; sin embargo cuando se trata de aplicaciones que deben controlar la operación de diferentes departamentos, dentro de la organización en un intento de crear un administrador centralizado de los procedimientos, en este caso las reglas de negocio repercuten entre los usuarios, entre los perfiles, departamentos, etc. Si en aplicaciones grandes no se identifican adecuadamente, podemos llegar a un punto donde la aplicación no satisfaga los requerimientos no explícitos.
Es muy común dentro de una misma empresa identificar tareas que se realizan en la misma organización y que según el departamento que la realiza se desarrolla con diferentes reglas. Los miembros de ese departamento desconocen las reglas del otro.
El concepto de Regla de negocio ofrece una forma de organizar cada elemento que deba ser identificado dentro de la lógica de la aplicación, y que por su naturaleza requiera ser implementada de una forma en particular. Con esto podemos decir que la regla existe como una verdad, sin embargo la forma de aplicarse dependerá de la implementación realizada.
A simple vista podemos notar que este concepto no es simple de abstraer, desde el punto de vista de la informática. El reto consiste en lograr la definición detallada, identificar donde debe aplicarse, como se debe aplicar, quien la aplica, que información se tiene al momento de aplicarla, que cambia, etc.
Hacer que una pieza de código pueda interpretar estas reglas de forma dinámica, es un reto muy ambicioso, para cualquier lenguaje de programación.
Crear un framework de esta naturaleza requiere de un diseño cuidadoso, donde una omisión podría ocasionar graves errores, el diseño de este tipo de código no es muy obvio y requiere un conocimiento detallado y profundo de las reglas de negocio.
La tarea inicial y la más compleja al comienzo es determinar si lo que estamos clasificando como regla de negocio es en realidad eso o resulta ser otra entidad. El concepto es algo ambiguo en sí, y los requerimientos a su vez pueden ser clasificados dentro una amplia variedad de clasificadores. Es muy fácil confundir una validación, con una meta, un objetivo con una regla de negocios.
Esta misma ambigüedad confunde al que debe identificar los requerimientos y fácilmente podemos descubrir que lo que estamos desarrollando es un método de programación tradicional en vez de un motor que permita que las reglas de negocio sean dinámicas.

Una definición muy aceptada es:
Es la declaración que define o restringe algunos aspectos del negocio. En su descripción nos permite afianzar la estructura de negocio, el control del mismo o que influye en su comportamiento.
Sin embargo es razonable pensar que así como las reglas de negocio se pueden ver desde diferentes ópticas, esta definición no será del agrado de todos.
Lo que resulta ser un hecho innegable es que si logramos separar la lógica de negocios, de forma segura y correcta, podremos permitirle a los usuarios darle mantenimiento a las reglas del negocio usando su metodología y terminología. De esta manera mientras la operación no cambie, el sistema podrá adaptarse a los cambios de políticas y reglas que se requieran por mucho tiempo.