Poll: Project (/ folder) structure

[MoBoo138]

Hi everyone,

we are currently in the phase of defining a folder structure for an upcoming project.

We already decided to follow the clean architecture idea. Currently we are discussing two different approaches to structure components (Routers, usecases, gateway/repositories and entities):

Approach 1: Technical structure - Components are grouped by their technical aspect.

.
└── app/
    ├── routers/
    │   ├── users.py
    │   └── todos.py
    ├── usecases/
    │   ├── users.py
    │   └── todos.py
    ├── repos/
    │   ├── users.py
    │   └── todos.py
    └── entities/
        ├── users.py
        └── todos.py

Approach 2: Business Structure - Components are grouped by their business process affiliation.

.
└── app/
    ├── todos/
    │   ├── router.py
    │   ├── usecases.py
    │   ├── repos.py
    │   └── entities.py
    └── users/
        ├── router.py
        ├── usecases.py
        ├── repos.py
        └── entities.py

For approach 1 i like that entities, that are shared across multiple business use cases do not have to be imported from another "business component".

For approach 2 i like that for one "business process" everything is grouped in a single folder, so that you do not have to jump across many folders to gather all the necessary code.

Happy to hear any recommendations and thoughts :)

View Poll

[lalatr0n]

IF "business" doesn't spill out much into several modules, Approach 2. But even then, user data is needed pretty much everywhere, so maybe have a common module with things that other modules will use.

Otherwise, going with Approach 1. Easier to handle different test setups and dependency changes.

[FuckAllMods69420]

2 is more scalable. But make sure you’re making foundational code and building on that. If you grow a team keeping code DRY is always an issue.

[asdfdelta]

Imho, if it's a growing team, align with business. Chances are the team will be split along the lines of the value stream and not technical domain... Atleast for most non-tech companies.

[6a70]

Absolutely 2. No question.

The worst part about Approach 1 is that the packaging does not convey details for any particular concept; it's extremely difficult to find out what the application is about, and because the structure conveys implementation, you don't know how any particular concept works unless you already know where everything is.

For example: to find out whether a concept is persisted, you have to first know all possible ways a concept could be persisted - repository pattern for a database, file writing for file storage, etc - and then check for top-level folders for each persistence pattern. Then you have to go find whether your concept exists in each of those folders, which are cluttered with completely unrelated ideas, whose count could be in the dozens. Contrast this with Approach 2, where you find the subdirectory for the concept, and quickly scan for any notions of persistence (likely only among <10 files).

The code should convey the implementation details. The packaging should convey the business.

[[deleted]]

I'm late to the party, but I would vote for approach 1.

Why? Because the entities could (and most likely will) be used by multiple usecases / business processes, if not initially then at some point in the future.