00:14
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
で、今日は、タイトルになります。僕がですね、ずっと残していた、トゥードゥにしていたオニオンアーキテクチャっていうものを、キャッチアップしていきたいなっていうふうに思った次第です。
あとクリーンアーキテクチャもずっと本としては積んでて、最近設計論のお話を結構見ることが、自分で増やしたんですね。
なので設計の勉強してたら、オニオンアーキテクチャっていうものがどうしたって目につくので、どっかでやってみようと思いながら、去年は1年間ずっと放置していたので、思い越し上げて今からやっていこうというふうに思った次第ですね。
で、いくつか記事もたくさん出てますし、本もあったりするので、あんまり深くやるつもりはないし、簡単に導入できればそれでいいと思ってたんですけど、やっぱり設計のお話ってやればやるほど楽しくてですね。
キャッチアップ自体もすごく楽しいんですけど、こうやって構造とか考えるのって多分エンジニアで好きな人だいぶ多いんじゃないかと思ったりしたので、コードを書いてみたいとか、このアーキテクチャに沿った構成とかっていうのをやってみたいなと思った次第です。
で、私はなんだかんだフロントエンドの領域が大好きなので、フロントエンド領域でオニオンアーキテクチャの設計概念とか思想っていうのを取り入れたらどうなるのかな、みたいなのを個人でも考えてみたいと思いました。
誰かしら多分ブログ書かれてる気はしますし、リポジトリも存在すると思うんですけど、私自身でやってみたいっていうのはありますね。
で、まずは入門してみようというところで、いつも通りチャットGPT、GPT-4にオニオンアーキテクチャとはなんぞやっていうのを簡単に説明してくれよっていう風に投げてみた感じですね。
で、僕はまだ勉強、今から始めると思うので、プーンっていうような概要のお話で今日終わってしまうんですけど、まずGPT-4くんの回答をちょっと読みますと、
オニオンアーキテクチャというのはソフトウェアのアーキテクチャデザインパターンの一つであって、ソフトウェアのコンポーネント複数の層、レイヤーですね。
っていうようなものに分割をし、それぞれの層が特定の役割を果たすように設計するアプローチです。
このアーキテクチャというのは内部の高度が外部に依存しないようにし、柔軟性やディスタビリティを向上させることを目的としています。
話し掛かりでレイヤードアーキテクチャとか多層アーキテクチャみたいな日本語もあったりしますけど、あの辺の話っぽいですよ。
一般的にオニオンアーキテクチャというのは内側から外側に向かって以下のような層、レイヤーを持つと。
一番はドメイン層、内側の層ですね。
ではビジネスロジックだったりアプリケーションのコア機能を含む層です。
この層は他の層からも独立していて、ビジネスルールやデータモデルっていうのを定義していきましょう。
2つ目がアプリケーションサービス層だと。
名前はGPTが勝手に言ってるので、もしかしたら名前が違うかもしれないですけど。
03:02
第2層が今言った通りアプリケーションサービス層だと言ってます。
こちらはドメイン層をラップして外部からのリクエストを受け取って適切なドメインオブジェクトを操作させる層ですよと。
アプリケーションのエントリーポイントとして機能し、外部のクライアントとのインタラクションを処理します。
ラスト3つ目がインフラストラクチャー層ですね。外部の層と言われてます。
これはシステム外部との連携を担当する層です。名前の通りそのまんまですよと。
オニオアーキテクチャーというのはコードの依存関係を逆転させることで、
内部のコードが外部のコードに依存しないようにするため、テスト容易性だったり保守性を高めるのに役立ちます。
各層が特定の役割を持つため、変更を行った場合にも影響を最小限に抑えられるメリットがあります。
メリットがあるんだからデメリットはどうなのかというので、デメリットの話も聞いてみたんですけど、
オニオアーキテクチャーはデメリットを一応4つぐらいGPT-4は教えてくれましたけど、
1つは複雑性だそうですね。プロジェクトの規模とか要求に応じて複雑になる可能性があると。
これは別にどの設計でもそうなんですけど、そのレイヤーとか層の追加によって適切な設計が必要になるため、
小規模のプロジェクトでは逆に過度に複雑と感じられることもあると。
規模感は確かにあるかもしれないですね。そこまでの設計とかレイヤーを考えなきゃいけないというような規模感ならばわかりますけど、
そうじゃないライトなアプリケーションとかプロダクトであれば別にそこまで設計しなくても良いだろうというところはあるかもしれないですね。
2つ目に学習コストが挙げられています。オニオアーキテクチャーの導入には学習コストがかかる場合があります。
開発チームはアーキテクチャーの原則やパターンを理解してそれに従って行動設計する必要があります。
これも他の設計ともそうですけど、ちゃんとこういう手法とかフレームワーク的なアーキテクチャーを導入するのであれば、
それを理解している方がコアなところをやっていただかないとカオスなアーキテクチャーになりそうだというのはもちろんあるので、
せめてレビュアーだけでも確かに入ってほしいなと思いますね。
3つ目、冗長性の話です。こういうレイヤーのアーキテクチャーをするときは、層ごとにコードを分割するため一部のコードが冗長になる可能性があるよと。
これは開発時間とコードベースのサイズを増加させる可能性がありますので、
ここもコードレビューでしっかりブロックというか対処していきたいところはありますけど、
どうやったって冗長性はどこか人間がコードを書く限りは生まれる可能性が多いので、
ここは確かにデメリットとしてずっと頭の片隅に入れておいたほうがいいかもしれないですね。
ラスト、4つ目は適用範囲です。
オニオンアーキテクチャーはすべてのプロジェクトに適しているわけではない。そりゃそうだよね。
小規模のプロジェクトとか特定の要件に適したアーキテクチャーがある場合はオニオンアーキテクチャーの導入が適切ではないよみたいなところもあるので、
ケースバイケースで皆さんちゃんと考えてねというお話でした。
名前の通りオニオン、玉ねぎなので、玉ねぎって皮どんどん剥きやすいじゃないですか。
というようなレイヤーに分けるってところがコアだと思うので、
結果的にはまずオニオンアーキテクチャーをしっかりやるには、
その前段となる階層化アーキテクチャー、多層アーキテクチャーとかレイヤードアーキテクチャーとか名前がたくさんあって、
どれがどれなんかちょっと今僕の中でまとまりついてないんですけど、
06:01
まずはそこをやるべきでしょうというのが前提にありそうなので、
オニオンアーキテクチャーをやる前にまずは多層アーキテクチャー、レイヤードアーキテクチャーのところを見たいなというふうに思った次第ですね。
まずは多層アーキテクチャーを見ているんですけど、
名前の通りアプリケーションを複数の層に分けていて、
それらを独立したモジュールとして開発とか保守をするというような考え方、概念ですね。
各層というのは必ずインターフェースというのを定義して、
それをモジュール化されたソフトウェアとして切り出しておくと。
各レイヤーはそのインターフェースを通じてやり取りをするというふうにしっかり分離する。
そこが抽象化と言われたりするやつですね。
こうすることでしっかり責務を分けて、お互いの役割を分けて分割ができるというお話です。
またこれはテクノロジーの進歩とか要求の変化ですね。
現場の要求の変化に合わせて各層を個別に置換することもできたりするというので、
ここが抽象化のメリットでもあったりします。
一応多層アーキテクチャの起源と編成みたいのがあったので軽く見てますが、
元々は3層ですね。3レイヤーとか3ティアーとか言われたりしますけど、
3層という用語とか多層アーキテクチャという用語はRATIONALというものが起源とされているらしいです。
RATIONALとはIBMソフトウェアブランドの一つでソフトウェア開発のライフサイクル基盤を提供していると。
RATIONALソフトウェアという独立ソフトウェア企業だったけど、
2003年に買収されて統合されたというところが起源であるとされている。
これどうなんですかね。諸説すごくありそうですけど、まずはそういう説があると。
一般的にティアーというのは物理的に異なるサーバーで、
レイヤーと言われたらソフトウェア上の役割分担であると解釈されるらしいです。
日本語ではどちらもSOと訳されてしまうため、英語の原義を確認することはとても重要です。
意味では僕らはソフトウェアを扱うので、レイヤーという言葉を使う方がより元々の定義に沿ってそうな気がしましたね。
ただ英語でティアーと書かれていてもソフトウェア的に役割分担を意味している場合もあるため非常に厄介ではあるというので、
ここは言葉の進化とか変化によってみんなが受け入れたってことはあるでしょうけど、
僕は厳密にやりたい話なので、今度からちゃんと明確にレイヤーって分けようと思います。
ティアーって聞いたら、もとろく物理的な話なのかなっていうのを片隅に入れながらちょっと話しようかなと思いました。
時代の変化によって揺れていることは事実としてあるよってことでした。
多層アーキテクチャの例としていろんなものがあるんですけど、
いわゆるソフトウェアエージェントによって実行されるクライアントサーバーモデルの位置形態とかはまさにそれだよね。
ユーザーとデータベース間とデータの要求サービスにミドルウェアというのを導入するようなアプリケーションというのも多層アーキテクチャと言えたりするっていうところですね。
昔のMVCとか昔ありましたよね。モデルビューコントローラーとかあったと思うんですけど、
あの辺の話はここに立脚した考え方な気がしますね。
さっきのクライアントサーバーアーキテクチャのモデルでいくと、
ユーザーインターフェースとビジネスロシックとデータベースという三つの層に分けたりするとかいうようなやつですね。
その辺がいわゆる多層アーキテクチャと言われるような概念の話です。
09:01
他にもレイヤードアーキテクチャとか厳密な言葉はあるんでしょうけど、
根本的にはそういう分け方をするということですね。
コントローラー側とモデル側とビュー側と三つに分けていくような概念で一体と思います。
ビューというかユーザーインターフェースですね。
大元のオニオンアーキテクチャの話に戻りますと、
そういう改造化アーキテクチャっていうのをしっかり知った上で行かないといけないんですけど、
続いて続く話が先ほどのGPT君も言ってたんですけど、
次は依存性の話があった通りで、
オニオンアーキテクチャを理解するには依存性逆転の原則というのが理解しなきゃいけないというので、
依存性アーキテクチャの原則の話を次に見ていきたいと思うんですけど、
すみません今日は早いですけど、ここで終わっていきたいと思います。
明日は続きですね。依存性逆転の原則をちょっと勉強してやっていきたいと思いますので、
興味あればまた来てみてください。
それやったら明日はちゃんとオニオンアーキテクチャ本論に入れたら入りたいなというところですね。
ちょっと僕の理解が浅かったりするので、
多少のミスとかもし間違いがあったら言っていただいて構わないので、
ぜひぜひまさかりお願いします。
あと、今から学ぶ方も一緒に学んでいけたらと思いますし、
どっかでオニオンアーキテクチャの実装ですね、
プログラミングしてちゃんとリポジトリ公開もしたいと思ってますので、
一緒に勉強できたらなと思ってます。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
