Discussion of App Structure for 2.1

proposals
5

@swilgosz, thank you for your insight! I added a reply to your comment in the other thread.

I definitely agree that mailers belong in app or slices, since they are UI-centric like all of the other objects in that layer. This should give them free access to the assets in the asset pipeline. If the app is using a JS front end, like React, then I would expect to follow a pattern similar to Rails, where JS code is stored within asset directories in app, and then compiled to a public directory or something similar. In this case, JS-based business logic would be stored in app or its sub-directories, and not in lib.

Middlewares, if I understand you correctly, are part of the Rack app stack, but could invoke business logic in lib in the same way that the Hanami router/actions do (since Hanami is just another Rack app).

I don’t think that I am competent to respond to the third question about validations, but my instinct is to lean towards “boring controllers” (that is, super-thin), with validations in the business logic. This may not be workable in all cases.

In the other thread you made a comment that I thought would be best answered here. You said:

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

I believe that the app structure I proposed would lend itself well to DDD and the gradual adoption of the more advanced concepts you mentioned. I could see the fairy tale lifecycle of a Hanami app going something like this:

  • hanami new gives us a simple, straightforward app framework with sane defaults, clean and clear conventions, and security best practices built in. The UI of our app lives in app and the business logic is organized however we see fit in lib/awesome_app/– we could go all Sandi Metz or Uncle Bob crazy in here, but personally I would organize around interactors, entities, and repositories (based on ROM), similar to Hanami 1.x.

  • As the app grows, we start to split the UI into slices: web for the web user app, admin for user group admin functions, an API, and maybe a BI dashboard. Business logic remains in lib/awesome_app/, just as before.

  • As more features are added, complexity and coupling in the business logic begin to take a toll. We decide to break up business logic into bounded contexts (DDD, ftw!): within lib/awesome_app/ we create directories for gatekeeping for identity and authorization functions; billing; appointments; etc. Interactors, entities, and repositories are grouped into their respective bounded contexts. Calls between bounded contexts are routed through a job queue for asynchronous processing.

  • When our dev teams grow large enough that we need to reduce coupling even further, we can implement event sourcing, switch from the job queue to event listeners, and maybe convert selected transactions to event stores. At this point implementing a strategy like CQRS would be straightforward. Since this code is isolated in the repositories, the change is invisible to the entities.

  • When Elon Musk finally makes us an offer–and tells us how if we were real developers, we would use microservices–then his Tesla engineers will have an easy time converting our shiny Modular Monolith to his master plan (while we sip mai tais in Hawaii). :wink:

That sounds like a pretty compelling story to me! Especially compared to the massive investments companies like Gusto and Shopify have made to twist Rails internals and conventions just to get some of these same benefits. I think with Hanami 2.1, this vision could be built right in from the start!

Thank you for adding your thoughts to the conversation! :slight_smile:

1 Like