Ao criar um aplicativo a partir do zero, devo começar com o modelo orientado a objeto (OO) ou o modelo de relação de entidade (ER)?
Você pode tentar observar o princípio de adiar as decisões de arquitetura o maior tempo possível. O pensamento é que você saberá mais no futuro sobre o domínio do seu problema do que no momento - portanto, qualquer decisão tomada hoje é suspeita.
Outro bom princípio para combinar isso pode ser tentar primeiro tentar as partes mais arriscadas - o pensamento é que, se você faz as partes fáceis, descobre que as partes arriscadas o movem em uma direção diferente, você não tem refazer as partes fáceis. Arriscado aqui significa coisas que você não tem certeza de como deve fazê-las.
Dado esses dois, e como muitas vezes tento abordar as coisas da perspectiva do OO, você pode tentar começar primeiro com um modelo OO das partes mais arriscadas do seu aplicativo e implementar a menor quantidade possível de código que possa funcionar que satisfaça a requisitos de risco. Em seguida, comece a expandir seu modelo OO, conforme necessário, para adicionar a funcionalidade necessária. Durante todo o tempo, você pode adiar completamente sua decisão de usar SQL ou NoSQL ou arquivos simples ou armazenamento em nuvem ou qualquer outra coisa ... e você pode acabar descobrindo que não quer relacional (evitando a necessidade de um modelo de ER).
O modelo ER determina como os dados do aplicativo serão mantidos e o modelo OO decide como esses mesmos dados serão armazenados na memória ou enquanto o aplicativo estiver em execução. Portanto, o design do esquema do banco de dados (modelo ER) e o design da estrutura de classe (modelo OO) são considerações de design relacionadas e geralmente podem ser pensadas simultaneamente. De fato, se você estiver usando uma ferramenta de mapeamento objeto-relacional (ORM) , seu modelo de ER e seu modelo de OO podem ser o mesmo. Em outras palavras, suas classes (modelo OO) podem ser anotadas de forma que elas próprias especifiquem o modelo ER.
Antes de projetar, no entanto, verifique se você tem uma idéia muito boa dos requisitos reais do software, para que ele será usado, como será usado e quem o usará. Muitos desenvolvedores começam a pensar nas decisões de design antes de entenderem completamente as necessidades a serem tratadas pelo produto e acabam com um design inadequado para o verdadeiro objetivo do aplicativo.