Package by features, not layers

“Splitting packages by layers is just like splitting co-workers by profession instead of splitting them into organization teams.”

Imagine this ridiculous situation:

Managers company, Programmers company, Human Resources company and Marketing company, where the Programmers company will only have programmers and no managers, marketeers or human resources;

Packaging stuff together by what it is, and not by what it does, will only make you jump 10 times to the place you are looking for.

figure 1 - Small sample of a package-by-feature structure

Gains and Benefits

• By looking at the structure you can already tell what the app is all about (figure 1);
• Higher modularity;
• Easier code navigation;
• Higher level of abstraction;
• Separates both features and layers;
• More readable and maintainable structure;
• More cohesion;
• Much easier to scale;
• Less chance to accidentally modify unrelated classes or files;
• Much easier to add or remove application features;
• And much more reusable modules.

Do you concur? What is your approach?

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!