Leandro,
Tudo depende de quais arcabouços de arquitetura, de quais patterns ou ferramentas você quer utilizar ou mesmo se você trabalha numa empresa que tem uma área exclusiva de DBA para modelar e criar os objetos de banco e não tem a liberdade de deixar um nome de tabela como Cliente, por exemplo.
Por via de regra, a boa prática é não associar diretamente os objetos de banco de dados com os suas classes de domínio, se você usa DDD (Domain Driven Design), por exemplo, a ideia é que você modele e desenvolva sua aplicação sem sequer levar em consideração em como será persistido no banco de dados.
Entretanto, quando você utiliza uma ferramenta de ORM (Object-Relacional Mapping) como NHibernate ou Entity Framework, por padrão o seu modelo de classes será espelhado no banco de dados (há formas de você especificar pro ORM qual é o modelo de dados sem ser exatamente igual ao seu modelo de classes).
Um livro de referência de DDD é do Eric Evans, leia também sobre Repository Pattern e ORM.
No fundo é uma questão de critério de uso para cada caso, é bem comum agora utilizar ORM para microsserviços uma vez que o contexto é bem limitado, em outros casos você vai precisar de uma maior complexidade de modelo de dados para melhor desempenho, por exemplo.
Sei que trouxe mais dúvidas, do que respostas, essa não é uma questão tão simples rs