Discussion of App Structure for 2.1

[swilgosz]

I have added a rough idea of different approach, that we could maybe use for some inspiration to further discussion.

We could leverage slices, to achieve both: Input-based modules (admin, API, web), and business domains (ordering, booking, registering). Slice does not need to have actions and we could use DDD terminology to organize modules there if we wish.

Then the UI slices could import necessary components from business domains via the slice importing mechanism.

Hanami 2.0 App Structure

I thought about using slices in different ways, and because of how slices can export some components, and because we can load different slices conditionally, I came up with this idea (don’t know yet how it’ll work out). Use slices based on the interface type $ tree slices ├── slices │ ├── api │ ├── admin │ ├── web │ └── client Use slices based on the domain model $ tree slices ├── slices │ ├── ordering │ ├── publishing │ ├── booking │ └── registering I’m not sure, if allow…

Also, some questions raised by one of our team members related to this would be:

1. Business logic components don’t really need assets, while UI-oriented could need. How we would organize our assets pipeline to work with SPA
2. How to manage middlewares?
3. how to handle complex params validation with rules - where is the border, of using params, and when contract become a business-logic validaition? How do you distinguish between business model, and APP-level validations?

I’ll experiment with a sample OSS application very soon, but these questions are some that make me thiking a lot about the app structures in hanami.

I personally avoid using lib too much - I tend to place them things like: utils, and general, agnostic pieces of code, that will most likely be used by my whole app, and can be also extracted to external gems.