I've been trying to decide if I should include getters/setters in business entities. A few reason I have been through to include getters/setters but those are accompanied by an anti-reason as well. Find them below:
Insurance policy for type change: First it is extremely rare. Secondly, we can always add a new method for any new type.
Public APIs to offer backward compatibility: Just like you can leave an extra getter/setter for backward compatibility, you can also leave an extra property to support that. But even if I am somehow wrong here, it still doesn't justify have getters/setters for specific apps.
Immutability: Yes, we will need getters with private property for that. But that is a better reason for value objects than entities. Entities are mapped data and they are supposed to be created and updated. There may be cases where it will be good to have some property immutable but it still doesn't justify to always have getters/setters in entities. It only justifies to have getter for rare cases, also destroying the consistency of object where most properties are accessible directly, and one or more are accessible via getter.
So with all these reasons and their anti-reasons I am still confused if I should start writing an entity with getters/setters or without.
However, I will prefer to write an entity without getters/setters for sack for extremely good readability. An entity with a few properties all public is a lot more readable than the one with getters and setters.
I am looking forward to any solid reason to follow on this.