Вот как я всё это понимаю:
Entity это класс для работы с БД или другим хранилищем данных. Его задача заключается именно в предоставлении удобного интерфейса для работы с этим хранилищем для конкретно этой "структуре данных".
Model это класс, с которым работает весь окружающий код. Он должен быть удобным для работы с этой моделью данных. Его интерфейс никак не зависит от того, как именно хранятся данные и описывает только поведение этой модели. Модель это ведь не только запись/чтение данных, там достаточно много своих задач. А вот для записи/чтения данных внутри Modelи уже происходит работа с Entity. И если вдруг вы решили менять БД с какой-нибудь SQL на noSQL, сделать некоторые правки в работе с БД или т.п., то вы просто изменяете Entity класс, не влезая в логику модели или, упаси Боже, в бизнес-логику.
Проще говоря задача Entity работать с БД, задача Modelи - описывать поведение модели. Для хранения и получения данных в Модели используется Entity.
Что касается правильного подхода: если у вас проект небольшой и вам не нужно городить тонны кода для работы моделей (а-ля блог), то вся эта канитель с Entity пустая трата времени. Если же проект серьёзный, с последующей долгой поддержкой, то такое разделение логики сохранит множество нервов всей команде разработчиков.
И напоследок
знаменитая статья дяди Боба о чистой архитектуре