Quick answer : Using getter and setter methods in the way you describe will most likely be fine. And removing them will not solve any concrete problem.
Remember that encapsulation is about information hiding. Formally, what you want is a data structure - your private fields - that is only ever accessed and modified via a fixed set of routines - your methods. That improves maintenance, because if you want to change the inner data-structure, you only have to go through your finite set of routines to make the update, rather than the whole program. It's easy to see the advantage :) .
The problem in get/set come when you expose implementation information. Let's take the example of exposing a database connection. Suddenly, you declared to the world that your object talks to a database. Client code will use that connection to do other stuff. 2 years later, you remove the database, it's not needed anymore. But the client code expects a connection to the old database! You can't change your object the way you want, and you have to carry around useless junk... you have exposed details you shouldn't!
In another case, though, you don't have something to hide : A Customer is an ID, a name and a phone number. Don't hide that, it's the very thing client code needs! Multiple parts of the application require this to do their job : your UI will display a formatted version to the user, your database will save and read the value, a JSON library will serialize the information to send an order to a 3rd party. This is business information. It need to be accessible to be useful. In that case, a getter - and maybe a setter - is perfectly valid.
In your case : If the getter in your business logic hides your model, it's perfectly fine. Use them. A getter-less design may not be better.
As a finishing note : people are often against getter because of something called "tell don't ask". This is a whole different issue than encapsulation. It's a design philosophy, and the benefits are less clear than with information hiding. The latter was already known in the 70s, while the former is a more recent invention. "Tell don't ask" is wonderful for some applications - event driven ones in particular. Alas, it work poorly with CRUD applications, where the whole point is to ask about information. Assuming you're outside the specific set of problems "tell don't ask" solves, use getters without any guilt. Just remember to hide your implementation.