There are maybe two reasons this is a code smell. One reason is, that it may mean you don't have domain objects but instead you have value objects that just store data for manipulation by controller or manager classes. This is actually pretty common and amounts to procedural programming in an OO language. The "lots of managers" may be a hint that you need to integrate state logic, validation and other direct concerns into the domain objects so that they actually encapsulate something. Of course there are bigger hints such as the fact that you have no methods other than getter/setters.
The other reason its a code smell is that it may mean your domain objects don't actually relate to each other very well. For instance if you have an Account class that really doesn't know anything about Transaction class except that it is named Transaction and there can be more than one of them, then you again you don't really have a very vibrant business domain implementation. For example SavingsAccount should maybe know that it can't accept a DebitTransaction if the accountStatus is closed. A lot of implementations would leave this up to the manager.