Let us look at what properties Java beans have:
- No-argument constructor.
- Getters and setters for all state.
What does this mean, however?
- Can be constructed easily without dependencies.
- Simple state.
- Can be easily sent across a stream, to e.g. a file or a socket.
- No mention of behavior: while not forbidden, we are encouraged to have stateful but behaviorless objects.
This perfectly describes an object that models state, not behavior. In popular idioms such as MVC or MVVM, a bean is a model.
If you have an object that represents data that can be passed around between objects or with other systems, that is a perfect candidate for a Java bean.
If you have an object that performs actions and directs traffic, that is not a candidate for a Java bean. If you have an object that manages a view, that is, converts state into a form suitable for presenting to the user, that is also not a candidate for a Java bean.
That being said, the three properties are not exclusive to Java beans and other objects may technically fall into the bean category. However, beans are just as much how we think about and use an object as the three constraints mentioned above.