A few, maybe ...

Remember that you’re out to design a computer program, not to design a world (nor even a simulacrum thereof).   It is easy to “design objects for the sake of their being objects,” but without a clear design-purpose for the “object metaphor” in your actual software.   If you cannot clearly articulate why a particular object, property, or method belongs in your design, nor why it makes the design “–er,” take it out immediately.

(IMHO...) The most important thing to “encapsulate” is logic, not data.   There is usually no practical advantage, for example, in exposing “SQL tables, rows and columns” as objects (i.e. an “ORM”), and in a great many instances it results in code that is (in my experience) much less maintainable.   Logic that ought to have been encapsulated (such as, any and all dependencies on “exactly how facts are being represented, stored and changed in a database”) winds up being exposed, and scattered hither-and-yon.   “The mere fact that you can handle hot things using soft, cuddly object-looking mittens, does not mean, de facto, that it is wisdom to fling hot objects all over the place.   Perhaps you’ve merely packed your spaghetti in lots of little boxes.”

Take “objects” (and every other metaphor known) just as far as they can usefully take your design, and not one whit farther.   If the metaphor makes your code cleaner, easier to understand, less “coupled,” more “compartmentalized” and so on and on and on ... proceed.   But when they come to an end ... stop.

Your instincts tell you that you have lost your way.   Undoubtedly, your instincts are correct, and it is wise that you stopped and timely asked for guidance.   “Trust your feelings, Luke.”