What classes should I put in domain package? [closed]

Question

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?

Answer 1

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.

Answer 2

I would encourage to put only domain model related classes like Customer, Order, etc in domain package.

And these domain specific entity classes which will be used in persistence layer to map domain entities and database tables and also these entities will be used to persist entity instance in database tables.

In modular based application development, this domain package you will never expose to outside world.