# Folder organization discussion proposal

**URL:** <https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319>\
**Category:** questions\
**Created:** [April 1, 2017, 1:09am UTC](https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319 "2017-04-01T01:09:43Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![victoraldecoa](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/victoraldecoa/32/263_2.png) [@victoraldecoa](https://discourse.hanakai.org/u/victoraldecoa)\
**Post date:** [April 1, 2017, 1:09am UTC](https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319/1 "2017-04-01T01:09:44Z")

</div>

Hi,

I learned yesterday about Hanami and so far I’m loving it! After seeing that it’s inspired by Uncle Bob’s Clean Architecture I instantly became a fan and intend to start using it in my next projects.

After trying on the beginners tutorial I noticed something that I thought could be improved: the folders’ structure. In the following lecture, Uncle Bob says something that I found really interesting: when you look at a Ruby on Rails folder you instantly know it’s a project developed in Rails. Isn’t it better if you look at the folder structure and instantly know what the project is all about (say a books organizer)?

Of course we shouldn’t just follow blindly everything that Uncle Bob says, but I think it’s nice to discuss it. What do you think about it? Should Hanami be reorganized in such way that features folders are in the root (or say in a “source” folder) and controllers, entities, repositories, templates, views and interactors inside each of them?

I hope this is a good place to put such discussion. I searched for other possibilities, but since it’s more of a philosophical long term issue, I thought this was best.

Best regards,  
Victor Aldecoa

---

<div class="post-metadata">

**Author:** ![jodosha](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/jodosha/32/710_2.png) [@jodosha](https://discourse.hanakai.org/u/jodosha)\
**Post date:** [April 18, 2017, 2:00pm UTC](https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319/2 "2017-04-18T14:00:07Z")

</div>

@victoraldecoa Thanks for you suggestion. Yes this is the right place where to discuss about it.

> [@victoraldecoa](#):
>
> Should Hanami be reorganized in such way that features folders are in the root (or say in a “source” folder)

We already have `lib/` folder where you can add interactors. For me, each interactor maps one-to-one the use cases of a project. By simply looking at `lib/bookshelf/interactors` you should be able to determine the use cases implemented by a project.

---

<div class="post-metadata">

**Author:** ![matt-from-toronto](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/matt-from-toronto/32/419_2.png) [@matt-from-toronto](https://discourse.hanakai.org/u/matt-from-toronto)\
**Post date:** [December 21, 2019, 7:03pm UTC](https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319/3 "2019-12-21T19:03:23Z")

</div>

I just stumbled across this topic after brainstorming this idea as well. I think it makes a lot of sense and I’m going to look whether I can tweak my Hanami project to support this. It makes way more sense intuitively IMO. Just to spell out what Victor is suggesting, the project directory would look something like:

```markdown
apps/web/
  products/
    index/
      partials/
        product/
          product.html.erb
          product.css
      index_action.rb
      index_view.rb
      index.html.erb
      index.css
      index.js
      images/
        an_image.jpg
  customers/
    etc...

```

So rather than structuring around functionality you structure around features / parts of the application. We don’t mental map an application by functionality and go through, say, each controller one by one, and then each view one by one, and then templates and then assets. We reason about and browse through the application by features / sections of the interface.

The huge benefit from this is it encourages developers to modularize their code and separate their concerns well. As it stands right now, when we categorize by functionality, the boundaries don’t feel clear because there are disparate subdirectories that depend on each other (for example `controllers/home/index.rb` interacts with `views/home/index.rb`, as opposed to `home/index/index_action.rb` and `home/index/index_view.html.erb` sitting side by side).

If anyone knows of any gotchas I should look out for when I tweak hanami to support this please let me know.

---

<div class="post-metadata">

**Author:** ![jdickey](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/jdickey/32/41_2.png) [@jdickey](https://discourse.hanakai.org/u/jdickey)\
**Post date:** [December 22, 2019, 10:01am UTC](https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319/4 "2019-12-22T10:01:46Z")

</div>

Luca and all,

Yes, we have `lib` for interactors. But not every project _uses_ interactors for all actions, and not every interactor implementation uses `lib`. By structuring the children of `apps/web` as _use cases_ (rather than either MVC-type component, or entities (as Matt’s tree suggests), the _application structure_ gives you at least broad hints about what the application does.

I can see where this would be a significant challenge, coming from the current convention-based structure of `apps`. The convention-following logic would have to adapt, either to something like Matt’s all-in-one-directory approach, or to replicating something like the current `controllsers`/`lib`/`models`/`views` structure for each `apps/web` (or `apps/whatever`) directory.

The benefit as I see it, again, would be at least two-fold: ease of onboarding new team members and getting them to think in terms of the app use cases rather than primarily in terms of the MVC structure; and reuse/extraction. Let’s say you wanted to take all the `products`-related use cases and extract them to a Gem, because you have (or are about to have) multiple applications that use similar business logic for dealing with your products. By extracting that Gem from `apps/web` in the proposed revised architecture, you can enforce consistency of entities, repository access, etc more easily and effectively than with the Hanami 1._x_ architecture. For those coming from a heavy Rails background, such a Gem would smack heavily of Rails engines but, with a more use-case-oriented focus, likely be easier for most junior-/mid-level devs to wrap their head around and contribute to efficiently.

Thoughts?

---

<div class="post-metadata">

**Author:** ![ianks](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/ianks/32/348_2.png) [@ianks](https://discourse.hanakai.org/u/ianks)\
**Post date:** [February 18, 2020, 6:08pm UTC](https://discourse.hanakai.org/t/folder-organization-discussion-proposal/319/5 "2020-02-18T18:08:19Z")

</div>

We would love to use “pods” style folders as well. Something like this would be ideal. I think it should be fairly compatible already, with some slight adjustments to how hanami router infers routes, and some adjustments to load paths.

```auto
apps/web/posts

├── controller.rb
├── template.html.erb
├── assets
│ └── javascripts
│ └── comment-on-post.js
└── view.rb

```