When we start to develop an application, we use packages to logically organize our classes, and almost always there is a package called domain (like com.raysis.reportgen.domain). My question is what we should and what shouldn't put in this package? Is there a standard definition or is it just about programmers taste?
Earlier I read something about it here: What is Java domain model?
Agile guru Robert C. Martin defined several software package metrics in his seminal book Agile Software Development: Principles, Patterns, and Practices. People have debated how useful metrics like afferent and efferent couplings are in practice, where and how the metrics should apply, etc. Regardless where you stand in the debate, the metrics do provide a nice objective, quantifiable way to measure coupling. You can then do what you wish with the information.
Generally, you should focus more on the package level, as you are doing, than at the class level. If a package is changing a lot, limit the number of packages whose members depend on this package. Conversely, if a package is stable, encourage other packages to depend on it. Another rule of thumb is that you know a package has good cohesion when changing the API for one class in the package means having to change the API of all the other classes in the package.
You can also look at these principles as the package-level versions of some of the OO class principles Martin espouses like the Single Responsibility Principle.