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

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this 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.

Answer 3

You should put classes which constitute you domain model. To find out what belongs to domain model and what doesn't let's start from the definition. Wikipedia says

Domain model describes the various entities, their attributes, roles,
and relationships, plus the constraints that govern the problem domain

So you should put there classes which represent above concepts in the code. There are other classes in you code which are not part of domain model. Some of them:

1. classes facilitating database access - belongs to DAO layer
2. classes responsible for presenting data to user - belong to Presentation

Answer 4

Package organisation is basically always a developer choice. AFAIK there aren't strict standards about how to arrange your package structure.

Obviously there are some best practices and Java convention that you should follow in your projects to maintain your classes and define their "concerns".

Usually domain sub-package is used to place domain objects (or model objects) mainly in projects implemented around MVC pattern, but not only. Model objects could map tables in your DB (if you are using an ORM) or they are just classes that represent the entities involved in your application logic.