<p>First of all, I know how to build a Java application. But I have always been puzzled about where to put my classes. There are proponents for organizing the packages in a strictly domain oriented fashion, others separate by tier.</p>

<p>I myself have always had problems with </p>

<ul>
<li>naming, </li>
<li>placing</li>
</ul>

<p>So,</p>

<ol>
<li>Where do you put your domain specific constants (and what is the best name for such a class)?</li>
<li>Where do you put classes for stuff which is both infrastructural and domain specific (for instance I have a FileStorageStrategy class, which stores the files either in the database, or alternatively in database)?</li>
<li>Where to put Exceptions?</li>
<li>Are there any standards to which I can refer?</li>
</ol>

[{'answer_id': 7599, 'author': 'graham.reeds', 'author_id': 342, 'author_profile': 'https://Stackoverflow.com/users/342', 'pm_score': 2, 'selected': False, 'text': "<p>Class names should always be descriptive and self-explanatory. If you have multiple domains of responsibility for your classes then they should probably be refactored.</p>\n\n<p>Likewise for you packages. They should be grouped by domain of responsibility. Every domain has it's own exceptions.</p>\n\n<p>Generally don't sweat it until you get to a point where it is becoming overwhelming and bloated. Then sit down and don't code, just refactor the classes out, compiling regularly to make sure everything works. Then continue as you did before.</p>\n"}, {'answer_id': 7610, 'author': 'Kieron', 'author_id': 588, 'author_profile': 'https://Stackoverflow.com/users/588', 'pm_score': 2, 'selected': False, 'text': "<p>Use packages to group related functionality together.</p>\n\n<p>Usually the top of your package tree is your domain name reversed (<code>com.domain.subdomain</code>) to guarantee uniqueness, and then usually there will be a package for your application. Then subdivide that by related area, so your <code>FileStorageStrategy</code> might go in, say, <code>com.domain.subdomain.myapp.storage</code>, and then there might be specific implementations/subclasses/whatever in <code>com.domain.subdomain.myapp.storage.file</code> and <code>com.domain.subdomain.myapp.storage.database</code>. These names can get pretty long, but <code>import</code> keeps them all at the top of files and IDEs can help to manage that as well.</p>\n\n<p>Exceptions usually go in the same package as the classes that throw them, so if you had, say, <code>FileStorageException</code> it would go in the same package as <code>FileStorageStrategy</code>. Likewise an interface defining constants would be in the same package.</p>\n\n<p>There's not really any standard as such, just use common sense, and if it all gets too messy, refactor!</p>\n"}, {'answer_id': 8335, 'author': 'bpapa', 'author_id': 543, 'author_profile': 'https://Stackoverflow.com/users/543', 'pm_score': 0, 'selected': False, 'text': '<p>One thing I\'ve done in the past - if I\'m extending a class I\'ll try and follow their conventions. For example, when working with the Spring Framework, I\'ll have my MVC Controller classes in a package called com.mydomain.myapp.web.servlet.mvc\nIf I\'m not extending something I just go with what is simplest. com.mydomain.domain for Domain Objects (although if you have a ton of domain objects this package could get a bit unwieldy).\nFor domain specific constants, I actually put them as public constants in the most related class. For example, if I have a "Member" class and have a maximum member name length constant, I put it in the Member class. Some shops make a separate Constants class but I don\'t see the value in lumping unrelated numbers and strings into a single class. I\'ve seen some other shops try to solve this problem by creating SEPARATE Constants classes, but that just seems like a waste of time and the result is too confusing. Using this setup, a large project with multiple developers will be duplicating constants all over the place.</p>\n'}, {'answer_id': 8400, 'author': 'Bryan Denny', 'author_id': 396, 'author_profile': 'https://Stackoverflow.com/users/396', 'pm_score': 0, 'selected': False, 'text': '<p>I like break my classes down into packages that are related to each other.</p>\n\n<p>For example:\n<strong>Model</strong> For database related calls</p>\n\n<p><strong>View</strong> Classes that deal with what you see</p>\n\n<p><strong>Control</strong> Core functionality classes</p>\n\n<p><strong>Util</strong> Any misc. classes that are used (typically static functions)</p>\n\n<p>etc.</p>\n'}, {'answer_id': 8438, 'author': 'Michael Neale', 'author_id': 699, 'author_profile': 'https://Stackoverflow.com/users/699', 'pm_score': 2, 'selected': False, 'text': "<p>I think keep it simple and don't over think it. Don't over abstract and layer too much. Just keep it neat, and as it grows, refactoring it is trivial. One of the best features of IDEs is refactoring, so why not make use of it and save you brain power for solving problems that are related to your app, rather then meta issues like code organisation.</p>\n"}, {'answer_id': 8594, 'author': 'cringe', 'author_id': 834, 'author_profile': 'https://Stackoverflow.com/users/834', 'pm_score': 4, 'selected': False, 'text': "<p>I'm a huge fan of organized sources, so I always create the following directory structure:</p>\n\n<pre><code>/src - for your packages &amp; classes\n/test - for unit tests\n/docs - for documentation, generated and manually edited\n/lib - 3rd party libraries\n/etc - unrelated stuff\n/bin (or /classes) - compiled classes, output of your compile\n/dist - for distribution packages, hopefully auto generated by a build system\n</code></pre>\n\n<p>In /src I'm using the default Java patterns: Package names starting with your domain (org.yourdomain.yourprojectname) and class names reflecting the OOP aspect you're creating with the class (see the other commenters). Common package names like <em>util</em>, <em>model</em>, <em>view</em>, <em>events</em> are useful, too.</p>\n\n<p>I tend to put constants for a specific topic in an own class, like <em>SessionConstants</em> or <em>ServiceConstants</em> in the same package of the domain classes.</p>\n"}, {'answer_id': 13283, 'author': 'Brian Laframboise', 'author_id': 1557, 'author_profile': 'https://Stackoverflow.com/users/1557', 'pm_score': 6, 'selected': True, 'text': '<p>I\'ve really come to like Maven\'s <a href="http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html" rel="noreferrer" title="S">Standard Directory Layout</a>.</p>\n\n<p>One of the key ideas for me is to have two source roots - one for production code and one for test code like so:</p>\n\n<pre><code>MyProject/src/main/java/com/acme/Widget.java\nMyProject/src/test/java/com/acme/WidgetTest.java\n</code></pre>\n\n<p>(here, both src/main/java and src/test/java are source roots).</p>\n\n<p>Advantages:</p>\n\n<ul>\n<li>Your tests have package (or "default") level access to your classes under test.</li>\n<li>You can easily package only your production sources into a JAR by dropping src/test/java as a source root.</li>\n</ul>\n\n<p>One rule of thumb about class placement and packages:</p>\n\n<p>Generally speaking, well structured projects will be free of <a href="http://en.wikipedia.org/wiki/Circular_dependency" rel="noreferrer">circular dependencies</a>. Learn when they are bad (and when they are <a href="http://beust.com/weblog/archives/000208.html" rel="noreferrer">not</a>), and consider a tool like <a href="http://www.google.ca/search?q=JDepend&amp;ie=utf-8&amp;oe=utf-8&amp;aq=t&amp;rls=org.mozilla:en-US:official&amp;client=firefox-a" rel="noreferrer">JDepend</a> or <a href="http://www.hello2morrow.com/products/sonargraph" rel="noreferrer">SonarJ</a> that will help you eliminate them.</p>\n'}, {'answer_id': 41544, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 2, 'selected': False, 'text': '<p>One thing that I found very helpful for unit tests was to have a myApp/src/ and also myApp/test_src/ directories. This way, I can place unit tests in the same packages as the classes they test, and yet I can easily exclude the test cases when I prepare my production installation.</p>\n'}, {'answer_id': 43779, 'author': 'Peter Hilton', 'author_id': 2670, 'author_profile': 'https://Stackoverflow.com/users/2670', 'pm_score': 2, 'selected': False, 'text': '<p>Short answer: draw your system architecture in terms of modules, drawn side-by-side, with each module sliced vertically into layers (e.g. view, model, persistence). Then use a structure like <em>com.mycompany.myapp.somemodule.somelayer</em>, e.g. <em>com.mycompany.myapp.client.view</em> or <em>com.mycompany.myapp.server.model</em>.</p>\n\n<p>Using the top level of packages for application <em>modules</em>, in the old-fashioned computer-science sense of <a href="http://en.wikipedia.org/wiki/Modular*programming" rel="nofollow noreferrer">modular programming</a>, ought to be obvious. However, on most of the projects I have worked on we end up forgetting to do that, and end up with a mess of packages without that top-level structure. This anti-pattern usually shows itself as a package for something like \'listeners\' or \'actions\' that groups otherwise unrelated classes simply because they happen to implement the same interface.</p>\n\n<p>Within a module, or in a small application, use packages for the application layers. Likely packages include things like the following, depending on the architecture:</p>\n\n<ul>\n<li><em>com.mycompany.myapp.view</em></li>\n<li><em>com.mycompany.myapp.model</em></li>\n<li><em>com.mycompany.myapp.services</em></li>\n<li><em>com.mycompany.myapp.rules</em></li>\n<li><em>com.mycompany.myapp.persistence</em> (or \'dao\' for data access layer)</li>\n<li><em>com.mycompany.myapp.util</em> (beware of this being used as if it were \'misc\')</li>\n</ul>\n\n<p>Within each of these layers, it is natural to group classes by type if there are a lot. A common anti-pattern here is to unnecessarily introduce too many packages and levels of sub-package so that there are only a few classes in each package.</p>\n'}, {'answer_id': 66745, 'author': 'Sébastien D.', 'author_id': 5717, 'author_profile': 'https://Stackoverflow.com/users/5717', 'pm_score': 4, 'selected': False, 'text': '<p>Where I\'m working, we\'re using Maven 2 and we have a pretty nice archetype for our projects. The goal was to obtain a good separation of concerns, thus we defined a project structure using multiple modules (one for each application \'layer\'):\n  - common: common code used by the other layers (e.g., i18n)\n  - entities: the domain entities\n  - repositories: this module contains the daos interfaces and implementations\n  - services-intf: interfaces for the services (e.g, UserService, ...) \n  - services-impl: implementations of the services (e.g, UserServiceImpl) \n  - web: everything regarding the web content (e.g., css, jsps, jsf pages, ...)\n  - ws: web services</p>\n\n<p>Each module has its own dependencies (e.g., repositories could have jpa) and some are project wide (thus they belong in the common module). Dependencies between the different project modules clearly separate things (e.g., the web layer depends on the service layer but doesn\'t know about the repository layer).</p>\n\n<p>Each module has its own base package, for example if the application package is "com.foo.bar", then we have:</p>\n\n<pre><code>com.foo.bar.common\ncom.foo.bar.entities\ncom.foo.bar.repositories\ncom.foo.bar.services\ncom.foo.bar.services.impl\n...\n</code></pre>\n\n<p>Each module respects the standard maven project structure:</p>\n\n<pre><code>   src\\\n   ..main\\java\n     ...\\resources\n   ..test\\java\n     ...\\resources\n</code></pre>\n\n<p>Unit tests for a given layer easily find their place under \\src\\test... Everything that is domain specific has it\'s place in the entities module. Now something like a FileStorageStrategy should go into the repositories module, since we don\'t need to know exactly what the implementation is. In the services layer, we only know the repository interface, we do not care what the specific implementation is (separation of concerns).</p>\n\n<p>There are multiple advantages to this approach:</p>\n\n<ul>\n<li>clear separation of concerns</li>\n<li>each module is packageable as a jar (or a war in the case of the web module) and thus allows for easier code reuse (e.g., we could install the module in the maven repository and reuse it in another project)</li>\n<li>maximum independence of each part of the project</li>\n</ul>\n\n<p>I know this doesn\'t answer all your questions, but I think this could put you on the right path and could prove useful to others.</p>\n'}]
['https://Stackoverflow.com/questions/7596', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/917/']