3

I am wondering whether this is the correct way to handle my situation when packaging-by-feature. Use the following project structure as an example:

com.foobar.web.Bootstrap.java
com.foobar.web.TcpServer.java
com.foobar.web.RequestHandler.java

Everything part of the web feature is in the web package - good so far. As all of the page classes are homogeneous and use the same parent, is it bad practice to then put them in a new sub-package by layer/type to avoid seemingly empty packages? In effect:

com.foobar.web.pages.AbstractPage.java
com.foobar.web.pages.HomePage.java
com.foobar.web.pages.BuyPage.java
com.foobar.web.pages.SupportPage.java

It feels almost as if I am packaging by feature then sub-packaging by layer. I find this hard to avoid unless I place each individual page in their own lonely package (e.g. .home.HomePage.java, etc) which feels useless as they are on their own with no additional classes in their packages.

What is preferable, each in their own package .home.HomePage (package by feature only) or all homogeneous in a single plural package .pages.HomePage (package by feature, then type combined)?

1 Answer 1

5

As someone who has suffered under a package by layer system for years I appreciate what you're trying to do. However, you are trying to faithfully stick to your organizing principle even if it forces you to make silly choices.

Rather than fanatical devotion to your organizing principle let me encourage you to follow a concern:

Make it easy to find stuff.

The main reason to group things by feature is that when I'm creating or updating a feature I can find the files I'm concerned with all in the same place. Not every file groups nicely around a single feature. Don't scatter these files to the wind by expecting them to live sad lonely lives in their own package. Find SOME good way to organize them. If that seems like a layer then fine.

Think that a hybrid would be far to confusing? Consider this example:

enter image description here

hackernoon.com : package by features not layers

I mean for crying out loud it actually has a package CALLED features! So what are the others? No these packages are not all features. That's OK. It nicely gives me a clue when it's sliding from one kind of organizing principle to another. I feel like I can find stuff just fine and predict where I'd be putting new stuff. That's all I need.

2
  • What is not clear in this approach is how to deal with model classes when using ORMs such as Hibernate, especially those that have references across multiple features, for example: User -> "UserFeed". I would naturally put User into "shared" and "UserFeed" into newsfeed. But then you might have entities such as "Avatar" which is also bound to "User" and might have it´s own service and REST endpoint. Does "Avatar" now belong to shared or does it qualify as a feature together with it´s service and REST resource? Jan 23, 2021 at 9:33
  • Those are presentation files though not domain features
    – Ced
    Jul 8, 2022 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.