Al crear una aplicación desde cero, ¿debería comenzar con el modelo orientado a objetos (OO) o el modelo de entidad-relación (ER)?
Es posible que desee tratar de observar el principio de retrasar las decisiones arquitectónicas el mayor tiempo posible. La idea es que sabrás más en el futuro sobre tu dominio del problema que lo que sabes ahora, por lo que cualquier decisión que tomes hoy es sospechosa.
Otro buen principio para combinar esto podría ser tratar de intentar primero las partes más arriesgadas de sus requisitos: la idea es que si hace las partes fáciles, entonces descubre que las partes arriesgadas lo mueven en una dirección diferente, no tiene rehacer las partes fáciles. Arriesgado aquí significa cosas que no estás seguro de cómo debes hacerlas.
Dados estos dos, y dado que a menudo trato de abordar las cosas desde una perspectiva OO, primero puede intentar comenzar con un modelo OO de las partes más riesgosas de su aplicación e implementar una cantidad mínima de código que pueda funcionar que satisfaga el requisitos arriesgados Luego, comience a expandir su modelo OO según sea necesario para agregar la funcionalidad que va a necesitar. Mientras tanto, puede retrasar por completo su decisión sobre si usar SQL o NoSQL o archivos planos o almacenamiento en la nube o lo que sea ... y eventualmente puede encontrar que no quiere nada relacional (obviando la necesidad de un modelo ER).
El modelo ER dicta cómo se conservarán los datos de la aplicación, y el modelo OO decide cómo se almacenarán esos mismos datos en la memoria o mientras la aplicación se está ejecutando. Por lo tanto, el diseño del esquema de la base de datos (modelo ER) y el diseño de la estructura de la clase (modelo OO) son consideraciones de diseño relacionadas y, por lo general, incluso se puede pensar al mismo tiempo. De hecho, si está utilizando una herramienta de mapeo relacional de objetos (ORM) , su modelo ER y su modelo OO pueden ser uno y el mismo. En otras palabras, sus clases (modelo OO) pueden ser anotadas de tal manera que ellas mismas especifiquen el modelo ER.
Sin embargo, antes de diseñar, asegúrese de tener una muy buena idea de los requisitos reales del software, para qué se usará, cómo se usará y quién lo usará. Muchos desarrolladores comienzan a pensar en las decisiones de diseño antes de comprender completamente las necesidades que debe abordar el producto, y terminan con un diseño que no es adecuado para el verdadero propósito de la aplicación.