Hanami 2.0 App Structure

proposals
5

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).

  1. Use slices based on the interface type
$ tree slices
├── slices
│   ├── api
│   ├── admin
│   ├── web
│   └── client
  1. Use slices based on the domain model
$ tree slices
├── slices
│   ├── ordering
│   ├── publishing
│   ├── booking
│   └── registering

I’m not sure, if allowing nested slices could help us group those different slice types together, but because I can do

# config/slices/admin.rb

module Admin
  class Slice < Hanami::Slice
    import keys: ['interactors.order'], from: :ordering, as: :orders
  end
end

# config/slices/api.rb

module API
  class Slice < Hanami::Slice
    import keys: ['interactors.order'], from: :ordering, as: :orders
  end
end

I could merge those two ideas.

The slice for business domain does not need to even have the view/serializers folder, nor even actions in it. If you follow DDD terminology, you could look there for interactors, commands, events, aggregators, repositories, mailers etc.

For interface slices, you could expect to have some folders, like: views, templates, contracts, serializers.

If we would have a way to create nested slices:

$ tree slices
├── business
│   ├── ordering
│   ├── booking
├── web
│   ├── api
│   ├── admin
│   └── client

Then we could group them and have the file structure visually better.

At the moment, I’m just fiddling around with ideas, however, @dcr8898, I am a huge fan of event-sourced systems, CQRS and DDD and will happily attend all the discussions related to these architectural topics :). Thanks for starting this!