Sus fuentes de consejos son correctas cuando dicen que es el modelo de dominio. En muchos casos, alineará bastante estrechamente su modelo de datos también.
Donde el dominio y los modelos de datos difieren es que el modelo de datos es relativamente estático en forma (no contenido) mientras que su modelo de dominio agrega las restricciones y reglas específicas de su dominio. Por ejemplo, en mi modelo de datos (base de datos) represento la presión arterial como smallints (sistólica y diastólica). En mi modelo de dominio , tengo un objeto "lectura de presión sanguínea" que contiene valores para cada una de las dos lecturas y que también impone restricciones adicionales en el rango de valores aceptables (por ejemplo, el rango para sistólica es mucho más pequeño que para smallints) También agrega juicios cualitativos sobre estos valores (un PA de 150/90 es "alto").
La adición de estos aspectos del dominio del problema es lo que hace que el modelo de dominio sea más que solo el modelo de datos. En algunos dominios (por ejemplo, aquellos que se representarían mejor con un modelo de datos totalmente orientado a objetos y que se correlacionan pobremente en el modelo relacional), descubrirá que los dos divergen bastante significativamente. Sin embargo, todos los sistemas que he creado presentan un alto grado de superposición. De hecho, a menudo introduzco un número considerable de restricciones de dominio en el modelo de datos mismo a través de procedimientos almacenados, tipos definidos por el usuario, etc.
me gano en Wikipedia. –
Quién/Qué manipula y opera en el estado si el modelo existe solo para mantener el estado. Espero que no digas controlador o de lo contrario estaré confundido acerca de ellos también: | –
"Controlador: procesa y responde a eventos (normalmente acciones de usuario) y puede invocar indirectamente cambios en el modelo." El usuario invoca una acción y eso cambiará el modelo, causando una actualización de la vista. – crb