ドメインにおける問題を解決に導くのがアプリケーション
成瀬允宣氏：順番にクリーンアーキテクチャの図を説明していきます。まずEnterprise Business Rules。図の中ではEntitiesって書かれているものですね。
もしかしたらドメイン駆動設計を調べた方がいるかもしれないですけど、ER図とかのEntityと意味は一緒なんですけど、違うものです。クリーンアーキテクチャで言うEntityは何かというと、ビジネスルールをカプセル化したもの。いわゆるドメインオブジェクトがEntityと、僕は認識しています。
ドメインオブジェクト。ドメインの概念を表現する。ドメインって何かというと、ソフトウェアで解決しようする対象の領域のことです。だから、例えば運送業務をこなすアプリケーションだったら、その運送の世界がドメインといいます。ビジネスと言っても差し支えないです。ビジネスオブジェクト。ビジネスの概念を表現する、そういうオブジェクトの話です。詳しくはこのあとお話しします。
次、Application Business Rules。これUse Casesとも書いてあります。何かというと、アプリケーションレイヤー。アプリケーションの目的であるドメイン（ビジネス）の問題を解決するために、ドメインオブジェクトを束ねあげてユースケースを実現すると言うものですけど、わかりづらいですよね。
どういうものかというと、ビジネスを表現したオブジェクト、運送のトラックオブジェクトを作りました。でも、トラックオブジェクトができただけだと、運送業界を表現しただけで、まだそこには問題がありますよね。我々がソフトウェアを作るということは、そこの運送業界に対して、さっきドメインって言ったビジネスの世界を表現して、その表現を使ってソフトを作るんですよ。
Application、Applyは解決するという意味なんですけど、アプリケーションはその表現したものを使ってがんばってビジネスを助けるために、要するにソフトウェア……例えば何でしょうね。買い物するときにオーダー、注文とか注文を受け付ける受注とかっていう概念がありますが、それってビジネスのオブジェクトなんですよ。
でも、それを使って買い物カートを作るのは、現在のビジネスになかったものですよね。それをアプリケーションとして表現する。だから買い物かごは買い物かご機能を実現するためのオブジェクト。現在のリアルのビジネスにはなかったものを新たに作り出すというか、それらを組み合わせて解決に導くのがアプリケーションです。
なかなか難しい感じかな。詳しくはこのあとお話しするので、今はそういうものだなということを覚えていてください。
クリーンアーキテクチャの図には実装例がちゃんとある
次、Interface Adapters。ここはすごくわかりやすいと思います。具体的にどういったものかというと、Controllers・Presenters・Gateways。今日は先ほどみなさんにお話ししたゲームの例えがありますよね。Controllerはゲームのコントローラ。Presenterはディスプレイ。Gatewaysはデータを保存する場所。そしてMockとか。こういうイメージです。
（コメントにて「EBRにはパーツしか作らないんでしょうか？」）そうそう、Enterprise Business Rulesにはパーツ。もちろんパーツでその中の処理自体はあるんです。ドメイン、ビジネスのもともとあったものを表現するためのメソッドとかあるんですけど、例えばデータの永続化とかはそこでしないってイメージですね。
このInterface Adapters、このように例え話すると、こうなりますよね。ControllerとPresenterがあって。あれ、これなんか見たことありません？ この図の右下だ！
となると、右下に合わせていくと、ここにUse Case Interactorって書いてあって、同じようにUse Case Input Port、Use Case Output Port、右上の図とまったく同じようにしてつなぐことができるんです。
インターフェース。Gatewayが当てはまる理由は、Gateway、要するにアプリケーションが外に対してアクセスするものをGatewayと言います。だから、データを保存するためにアクセスする先のことをGatewayと言いますね。
じゃあこれを図に沿っていくと、＜I＞はインターフェースの意味です。Use Case Output PortとかUse Case Input Port、この図には実は「＜I＞」って書いてあるんですよ。これInterfaceですね。
それでControllerがInput Portに対して、Input Port、この矢印は、よく見ると普通の矢印と白抜きの矢印があります。UMLで言う「汎化」と「使用／依存」。ControllerはInput Portを使います。Use Case InteractorはUse Case Input Portを汎化します。Use Case InteractorがUse Case Output Portを使って、それをPresenterが実装する。
実は右下の図ってすごく大事なんですよ。クリーンアーキテクチャの図を見ると、左側の丸い図にばかり目が行っちゃうんですけど、実は右下にこうやって実装例が書いてあるんですね。これについてはまた詳しくやっていきます。
フレームワークをビジネスロジックに依存させたい
最後、Frameworks & Drivers。これは何かというと、クリーンアーキテクチャの定義では詳細なコードをギークなコードって言います。重要なのは、ビジネスロジックがこれに依存しないようにすることです。
依存とはどういうことかというと、ビジネスロジック上で例えばHTTPとかいう言葉を使わないとか、「エラーで赤くする」というところをビジネスロジックに書かない。そういうときには、赤くするまで書かずにエラーまででいいんですよ。依存しないようにすることによって、アプリケーション、ビジネスルールが守られる。
なんで守ろうとしているかというと、詳細なFrameworks & Driversに依存すると、ソフトウェアに大幅な変更が起きたときに耐えきれないんですよね。
フレームワークを変えた経験は、もしかしたらみなさん無いかもしれないですね。ソフトウェアを作ると、よく成功者サービスって15年後ぐらいにサービスを刷新しようかって話になるんですよ。そのときに何やるかというと、フレームワークを変えるんですよね。言語が同じだとしても、フレームワークのバージョンが変わっていたりするので。
例えばJavaで言うと、Play Frameworkから最近Spring Bootに変えようとか。みんな、StrutsからSpring Bootに変えようとか、そういう流れがなかった？ 知らないかな、みんな。
15年もサービスやっていると変わるんですよ。そのときにこの詳細な周囲、UIとかフレームワークとかに依存しちゃうと、ビジネスロジックってフレームワークは関係ないじゃないですか、そこまで修正が入ってしまう。これを避けたい。だから依存の方向を逆転させて、フレームワークをビジネスロジックに依存させたいんですね。
そうすることによって「フレームワークがもう古くなったから変えましょう」ってときに「ビジネスロジックまで変える必要ないでしょ」ということが実現できるんですね。これを実際に実現するのがDI（Dependency Injection）。
依存の方向を内向きにします。内側の変更は外に影響する。そんな方向を内向きにすることによって、ビジネスロジックでWebとかDBとかUIを使わないと、結果としてそれで差し替えが可能になります。ビジネスロジックでOracle前提のコード、「例えば『MySQLにしましょう。保守料が高いから』ってなったときに困るじゃん。困らないようにしようね」というのがこの考え方です。
（コメントにて）「5年でフレームワークを変えた」「変えきれなくて混在している」、あるよね（笑）。俺もこの間ね、入社して15年前のソースをやらされたからね、びっくりしましたね。つらかったー。
じゃあなんとなく流れがわかったかな。やりたかったことは、内側に依存させたい。要するにデータベースとかに依存したくない。結果として、それをやると、もちろんビジネスロジックの変更、フレームワークを変えたりの挿げ替えができるし、あとテストができるんですね。
テストができるってことはモックオブジェクト、テスト用、とりあえずメモリで動かしておこうということができるんですよ。それができるとAPIができてなくてもその先を作れたりするんですよ。データ保存、データベースがなくても、とりあえずビジネスロジックが作れるんですよ。それがしたい。
