Hanamiのアーキテクチャには２つの原則があります。
それはクリーンアーキテクチャとモノリスファーストです。モノリスファーストについては後日語るとして、クリーンアーキテクチャとは何なのでしょうか?自分なりの理解と考えをまとめてみたいと思います。

現時点での著者の考えなので間違いや理解不足が大いにあると思います。温かい目で読んで下さい。

クリーンアーキテクチャって?

まずはHanamiの公式を引用してみます。

The main purpose of this architecture is to enforce a separation of concerns between the core of our product and the delivery mechanisms. The first is expressed by the set of use cases that our product implements, while the latter are interfaces to make these features available to the outside world.

機械翻訳

このアーキテクチャの主な目的はプロダクトのコアと配信メカニズムの間の関心事の分離を強制することです。
プロダクトのコアは一連のユースケースで表され、配信メカニズムはこれらの機能を外部世界で利用できるようにするインターフェースです。

これだけだとよくわかりませんね。

クリーンアーキテクチャを理解するには、MVCアーキテクチャの問題点を理解し、クリーンアーキテクチャがどのようにして生まれたのかを考えるとわかりやすいと思います。

MVCアーキテクチャの問題点

MVCアーキテクチャ

MVCアーキテクチャについて考えてみたいと思います(ものすごく浅い理解なので然るべき人に怒られそうですが)。MVCアーキテクチャはこんなふうによく書かれると思います。

MVCアーキテクチャ

====================
| V (View)         |
====================
| C (Controller)   |
====================
| M (Model)        |
====================

View: 見た目の部分です。インターフェースでもあります。
Controller: ViewとModelの調整役です。
Model: ビジネスロジックです。

各レイヤーは自分と同じレイヤかそれ以下のことしか知りません。このように関心の方向を一方向にすることで複雑さを回避しようというのが根本的な考え方だと思います。

Modelのもう一つの役割

Modelはビジネスロジックを書く場所ですが、もう一つ役割があります。
それはインフラストラクチャの取扱いです。

Modelレイヤの２つの役割

========================
| V (View)             |
========================
| C (Controller)       |
========================
| M ビジネスロジック   |
| -------------------- |(薄い壁)
| インフラストラクチャ |
========================

インフラストラクチャレイヤではDBなどへのデータの保存や取出しを行います。

依存性の逆転原則

いったん話は変わって依存性の逆転原則の話です。

依存性の逆転原則とは

上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである
「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである

という原則です。

詳しくは説明しませんが(できませんが)、オブジェクト指向でプログラミングをする上で非常に大事な原則です。

MVCアーキテクチャへの問題点

依存性の逆転原則という観点でMVCアーキテクチャを見てみるとどうなるでしょうか?依存性の逆転原則では「抽象」に依存しろ、といっています。

MVCアーキテクチャでの「抽象」はどれでしょうか?それはビジネスロジックです。では実装の詳細はビジネスロジックに依存しているでしょうか? いえ、していないですね。先程見ていただいたようにビジネスロジックはインフラストラクチャに依存しています。

ビジネスロジックはインフラストラクチャに依存している

========================
| V (View)             |
========================
| C (Controller)       |
========================
| M ビジネスロジック   | <-インフラストラクチャに依存している!
| -------------------- |
| インフラストラクチャ |
========================

このことがMVCアーキテクチャの問題点であると著者は考えます。

MVCアーキテクチャへの依存性の逆転原則の適用とクリーンアーキテクチャの誕生

MVCアーキテクチャの問題点を解決するために依存性の逆転原則を適用してみましょう。
こうなります。

MVCアーキテクチャに依存性の逆転原則を適用

====================================
| V (View)  | インフラストラクチャ |
====================================
| C (Controller)                   |
====================================
| M ビジネスロジック               |
====================================

インフラストラクチャが一番上に来ました。これによりビジネスロジックが(ビジネスロジック自身以外には)どこにも依存しないようになりました。

これをもうちょっときれいにすると(適当)以下のようになります。

(https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.htmlから引用)

内側からざっくり説明すると以下のようになります(ちゃんと知りたい人はリンク先を読んで下さい)。

Entities: ビジネスロジック
Use Case: Entities間データの流れを制御します
Interface Adapters: データをいい感じの形式に変換します
Frameworks and Drivers: WebやDBなどすべての詳細を追いやるところです

上記の図では4層で構成されていますが、この数は重要ではありません。3層でもいいし、5層でもいいです。大切なのはビジネスロジックが中心にあるということです。

Hanamiのクリーンアーキテクチャ

Hanamiではどのようにクリーンアーキテクチャを実現しているのでしょうか?

1つはROM(Ruby Object Mapper)の採用があります。

ROMはORマッパーの一種ですが、EntityとRepositoryが完全に分離されていることが大きな特徴です。
クリーンアーキテクチャではEntityとRepositoryの分離は欠かせませんから、ROMはHanamiのアーキテクチャに大きく貢献しているといえます。

もう1つはインタラクタのサポートです。インタラクタはおそらくサービスやユースケースといったほうが通りがいいと思います。
Hanamiはインタラクタ層の実装を簡単にするためのツールを用意しています。これを使うことは必須ではありませんが、Hanamiでクリーンアーキテクチャを体現しようとしたときに多いに役立ってくれるでしょう。

インタラクタについてもうちょっと知りたいという人は前回の記事を読んでいただけると幸いです。

感想

正直、自分のスキルでクリーンアーキテクチャを語るのは時期尚早だった。
もうちょっと修行してきます。

参考

実践ドメイン駆動設計
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
http://hanamirb.org/guides/1.1/architecture/interactors/