# Hanami 2.0 App Structure

**URL:** <https://discourse.hanakai.org/t/hanami-2-0-app-structure/705>\
**Category:** proposals\
**Created:** [September 14, 2022, 3:14am UTC](https://discourse.hanakai.org/t/hanami-2-0-app-structure/705 "2022-09-14T03:14:48Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![dcr8898](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/dcr8898/32/625_2.png) [@dcr8898](https://discourse.hanakai.org/u/dcr8898)\
**Post date:** [December 8, 2022, 2:35am UTC](https://discourse.hanakai.org/t/hanami-2-0-app-structure/705/6 "2022-12-08T02:35:15Z")

</div>

@swilgosz

Slices are probably already flexible enough to use the organization strategy you suggest. This approach is conceptually similar to the [Component-Based Rails Application](https://cbra.info/), which orchestrates groups of unbundled Rails engines, each of which can provide any of the usual objects available in a standard Rails app (controllers, views, models, helpers, etc.).

A Gusto team member recently gave a [talk](https://www.youtube.com/watch?v=J9S0qiGkAQY) at RailsConf describing how they use [Packwerk](https://github.com/Shopify/packwerk) to create “packs” (complete with defined, enforceable interfaces) in a Rails monolith. These packs sound very similar to the way you are suggesting to use slices in Hanami 2.

Much of what I proposed is based on ideas from DDD and Hexagonal/Clean/Onion architecture. The goal of all of these strategies is to isolate the business logic and protect it with clearly defined APIs. I feel that this can best be accomplished by sticking to the Hanami 1.x convention of placing business logic in `lib`, and by extending the architectural model by providing a pathway to modularization.

---

_[View the full topic](https://discourse.hanakai.org/t/hanami-2-0-app-structure/705)._