Feature-first or Layer-first

At this stage, let's talk about Project Structure. When a team or an engineer starts to build an application or system, no matter if engineer is alone or there are several of them in a team, there should be setup some rules to keep the codebase clean, maintainable and scalable.

Table of contents:

1. Why do we need Project Structure?
2. Layer-first approach
3. Feature-first approach
4. Conclusion
5. What's next?

1. Why do we need Project Structure?

We told above that some rules should be setup when developing an application. The question is why we need them? Okay, there maybe several cases for system failure if some rules are not followed.

Firstly, a single junior engineer starts building an application, delivering features in a way he wants, not structuring properly, as fast as possible. The company is satisfied with the engineer's delivery of features. After a year of progress, business asks to change particular functionalities. The engineer has to go back to code he wrote a year or two ago and change it, but he can't remember why there's some part of the code, sees it is used in several places. He tries to change the code, but finds the second part broken, fixes the second part, first part is broken. Or maybe, he cannot find some class used in the feature. The thing is, he has been fast at delivering features for a year or two, but now he sees the codebase is out of control, very messy, not fixable - should be re-written. The system is neither maintainable nor scalable.

Secondly, let's say some maintainable issues are not faced yet. The company sees that development is starting to slow down and hires new engineer into project to speed up the development. However, the new comer clones and opens the project code, he understands nothing. He finds that classes used by feature are scattered around the project, those classes are re-used everywhere, finds some classes with thousands of lines of code that do many things. The outcome of the situation is, new engineer does not speed up the development.

There are many reasons to keep the codebase clean and that can be gained by structuring the codebase properly. Let's talk about two approaches for this: Layer-first approach and Feature-first approach.

2. Layer-first approach

Assume, you are developing small-mid application alone or in a small team. Then this approach is probably right for you.

When this approach is applied, we group the files based on their layer.

All Response/Request models from/to backend, API files, Local Storage files, Database files are stored in data directory.

All core entities, Use Cases, Repositories, Manager Classes, Exceptions into domain directory.

All screens, viewModels and their widgets into presentation directory.

These are just examples for each directory, of course, they are not limited with the provided example, there can be more. The folders and files can be named based on self preference as well.

Benefits:

• straightforward: when a feature to be implemented, an engineer just creates files in data, domain, presentation layers; connect them; deliver feature.
• less code: compared to feature-first approach, no extra data, domain directories for each feature are created.
• clean: clear what files to expect from the directories.

Drawbacks:

• code conflicts: since working in the same directories and files, sometimes conflicts arise in PRs.
• difficult to navigate: we expect what files to find in directories, but it takes time to find files of a particular feature.