2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
成瀬允宣氏:順番にクリーンアーキテクチャの図を説明していきます。まず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ができてなくてもその先を作れたりするんですよ。データ保存、データベースがなくても、とりあえずビジネスロジックが作れるんですよ。それがしたい。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには