Debería leer más sobre el diseño impulsado por dominio . Básicamente intenta capturar los requisitos de la empresa en un modelo puro (en su mayoría modelos de objetos) que puede realizar todas las tareas lógicas empresariales necesarias. Este modelo se puede invocar desde una capa de aplicación (por ejemplo, la vista o el controlador en MVC, en MVP lo llama y lo ajusta para la GUI en un presentador). El modelo también debe ser tan ignorante de la persistencia y otras cosas técnicas como sea posible.
Encapsular la lógica empresarial en un modelo de dominio de este tipo tiene algunas grandes ventajas:
- Reusabilidad
- Facilidad de uso y extensión
- Generalmente conduce a una mejor arquitectura
- Comunica claramente las coherencias y los requisitos comerciales ...
- ... y así mejora la comunicación entre desarrolladores, clientes, analistas, etc.
Recomiendo el libro de Eric Evan sobre diseño impulsado por dominio para leer más, ya que lo guiará en la dirección correcta y le dará algunos buenos ejemplos sobre dónde colocar qué lógica. Apuesto a que para cuando lo haya leído, un gran porcentaje de sus entidades contendrá más que datos planos .
Pero me resulta difícil planificar un enfoque en el que los Modelos manejen la lógica de negocios y sean clases completas en sí mismas.
Supongo que, por modelo, se refiere principalmente a entidades en este contexto. Poner lógica / comportamiento empresarial en las entidades no es una tarea trivial. Pero siempre hay que pensar en lo que una entidad es y lo que una entidad lo hace . ¿Tiene algunas responsabilidades o comportamientos? A veces está bien tener entidades planas si los comportamientos o las responsabilidades se expresan mejor como servicios.
Supongamos que tienes un animal. Si bien sus atributos se pueden guardar de manera plana en una base de datos, también tiene cierto comportamiento. Necesita comer Pero un herbívoro no comerá carne, por lo que debe asegurarse de que muestre su comportamiento cuando el programador quiera que consuma carne por la fuerza. Se puede mover y puede hacer su propio ruido único. Estas son algunas cosas que deberían modelarse en la entidad, por ejemplo. Seguro que no dependería de los servicios de procedimiento para hacer que esos animales coman, se muevan o hagan ruido.
Pero todos los ejemplos son superficiales sin un dominio comercial concreto. Por lo tanto, piense en su dominio comercial y en sus entidades, comportamientos y responsabilidades. Un dominio de otro negocio puede contener entidades que se parecen mucho a un extraño, pero de hecho son algo completamente diferente o muestran un comportamiento totalmente diferente. El modelo debe representar ante todo el dominio de sus usuarios lo más preciso posible.