1 of 2

Quick answer : Using getter and setter in the way you describe will most likely be fine. And removing them will not solve any concrete problem.

Longer answer

Rembember 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 routine - your methods. That improve maintenance, because if you want to change the inner data-structure, you only have to go through your finite set of routine to make the update, rather than the whole program. Its easy to see the advantage :) .

The problem in get/set come when you expose implementation information. Lets take the example of exposing a database connection. Suddenly, you declared to the world that your object talk to a database. Client code will use that connection to do other stuff. 2 years later, you remove the database, its not needed anymore. But the client code expect 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 other 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 need! Multiple part 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 hide 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. Its a design philosophy, and the benefit are less clear than with information hiding. The later was already know in the 70s, while the former is a more recent invention. "Tell don't ask" is wonderfull for some application - event driven one in particular. Alas, it work poorly with CRUD application, where the whole point is to ask about information. Assuming you're outside the specific set of problem "tell don't ask" solve, use getters without any guilt. Just remember to hide your implementation.