00:12
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
で、今日は、昨日に引き続き、オニオンアーキテクチャというものを勉強したいなと思っておりまして、
それの続きですね。昨日もやってたんですけど、そもそもオニオンアーキテクチャをやるとなると、前提知識として、
いわゆるレイヤードアーキテクチャに近い、いわゆる階層化アーキテクチャとか多層アーキテクチャとか名前いっぱいありますけど、
いわゆる物事をレイヤに分けて、それぞれで抽象化をして、インターフェースでやり取りをしましょうみたいなお話ですね。
っていうような概念だったりとか、オブジェクト志向みたいな概念だったり、その辺をやらないと、そもそもオニオンアーキテクチャにハイレイヤみたいな話をしてて、
昨日喋ってたんですけど、そのレイヤードアーキテクチャのお話をしているところで時間が来てしまったので、
今日はその続きとして、依存性逆転の原則のお話からちょっとやっていこうかなと思ってます。
ではやっていきたいと思いますけど、別にまだ僕は今から学ぶってところですし、
私はオブジェクト志向本当に初心者で、今まで全然やってこなかった人間なので、今からちゃんとオブジェクト志向を勉強しようというような感じです。
そんな文脈だというところを理解いただいてやっていきましょう。
依存性逆転の原則に関して記事を探したんですけど、これがまた大量に出てきてですね、どれ読もうかすごく悩ましかったんですけど、
研究者の間ではあまり信用しないウィキペディアからまず見ていきますかね。
依存性逆転の原則。オブジェクト志向設計の用語であったり、ソフトウェアモジュールを素結合にするという特別な形態を表現したコンセプトでもあって、
有名なソリッド原則とありますね。5つの原則の1つとして知られています。依存性逆転です。
定義としてはオブジェクト志向における従来の依存関係とは上位のモジュールから下位モジュールへの方向性を見ていました。
使用定義を担う上位モジュールを詳細実装になる下位モジュールから独立させて、各下位モジュールを別個保存するというものだったんですけど、
それに対して依存性逆転原則は以下の2点を提唱しております。
上位モジュールはいかなるものも下位モジュールから持ち込んではならない。
双方とも中小、いわゆるレイヤー、インターフェースとして依存するべきですよね。
2つ目は、中小は詳細に依存しはならない。
詳細、具体的な実装内容が中小に依存するべきであるというのはその通りですね。
この上位モジュールと下位モジュールの双方が中小に依存しなければならないという内容はそれまでの人々のオブジェクト志向の常識を覆しているものでしたよみたいな話をしていて、
そこからちょっと違う話になってくるんですけど、そういう感じのものですね。
とにかく上位と下位というざっくり2つに分けて、使用周りの話とかと実際の実装、詳細なところをしっかり明確に分離しましょうという話でした。
03:04
この依存性逆転の原則というのを適用することで、上位レイヤーのモジュールというのは低レイヤーの詳細に依存しないので、
ケースバイケースとか現場における実装をしなくても良くなりますよね。
それは実際の低レベルの方で上位レイヤーのものを利用する形で実装すれば良いというので、より汎用性が高まるというのは良い話ですね。
また柔軟性・保守性とも全然上がるんじゃないですかね。
中小化するというのはそういうお話ですので。
その辺のお話を踏まえた上で、実際にオニオアーキテクチャという話に入っていきたいと思います。
オニオアーキテクチャを調べていただくと、いわゆる円のやつですね。
同心円みたいな画像が出てきます。
内側から外側に向かって、ドメインモデルというのが一番コアなところにあります。
その1個上のレイヤーにドメインサービスというのがあります。
さらにその1個上のレイヤーにアプリケーションサービスというのがあって、ここにアプリケーションコアというものも1つ含まれております。
さらにその上ですね、広いレイヤーのところでインフラストラクチャー、そしてUI、そしてテストというような感じで、
オニオン、いわゆる玉ねぎですね。
玉ねぎ、海藻みたいな感じになっているじゃないですか。
向いていただくと分かりますけど、どんどん川ごとにレイヤーが分けられているみたいな感じで、
これが呼び方として分かりやすかったんでしょう。
オニオアーキテクチャという名前になっています。
本当にレイヤードアーキテクチャそのものじゃんという感じはありますけど、
そこにプラスアルファで設計の概念をしっかり組み込んだというのが、このアーキテクチャになるでしょうねというところです。
かなり分かりやすくていいんじゃないかなと思ったりしてますね。
ちなみにアーキテクチャとしては他にもいくつかあって、
先ほども何度も出しました、レイヤードアーキテクチャもあるし、
ヘキサゴナルアーキテクチャとか、今言ったオニオンアーキテクチャとか、
クリーンアーキテクチャですね。
みたいなものもあったりするんですけど、
今ちょっと僕設計周りハマっているので全部勉強しようと思いますけど、
一旦一個ずつ行くので今オニオンアーキテクチャですね。
先ほどの詳細説明した各層についての役割をざっくり話していきたいと思いますが、
一つ目は一番中心部分にありましたドメインモデル層というやつですね。
名前の通りビジネスドメインとかコアロジックだったりビジネスルールとかというものを担当するレイヤーになります。
いわゆるエンティティと言われる言葉だったりとか、バリオブジェクトなどで構成されて、
ビジネスオブジェクトとその振る舞いというのを表現していきますよという感じです。
エンティティとバリオブジェクトといわゆるDTT文脈でよく言われる言葉なので、
ちょっとそこまでやりだすと終わらないので、そこはまあまあ積極的に調べていただきたいという感じがありますね。
続いてもう一個上のレイヤードメインサービス層というやつですね。
先ほどのドメインモデルというものが持つ責務の一部を凝集させておくところになります。
ドメインモデルに直接関連する操作だったり、複数のドメインオブジェクトにまたがる操作というのが提供してくれるっぽいですね。
ドメインサービスというのはビジネスルールやビジネスロジックの実装を含む場合もあってですね、
ドメインモデルの一部として表現されることもあるというので、ここは厳密派の人たちか、ちょっと抽象的なものをやる人たちかで実装が変わるかもしれないですけど、
06:05
基本的にはビジネスロジックに関わる振る舞いのロジックを担当するってことですね。
あくまでこれはちゃんとインターフェースなどで配置していってやり取りできるようにする。
基本的には各レイヤー同士はインターフェースを通じてやり取りするのはあまり変わらないですけどね。
というのでドメインサービス層でした。
続いてもう一個上のレイヤーとしてアプリケーションサービス層というところに次は分ける層ですね。
こちらはアプリケーションの振る舞いを実装するという話です。
ユーザーインターフェースとか外部APIとのやり取りっていうのを担うところですね。
あとはビジネスロジックの組み立てとかドメインモデルへの操作も行うと。
アプリケーションサービス層でもドメインモデルに操作とかやり取りするんですね。
なんかちょっとレイヤーぶちこえた感じの書き方をしてますけど。
あとはアプリケーションサービスっていうのはドメインモデルの操作の組み合わせによってユースケースを実現するというので。
あとはトランザクションの管理とかエラーハンドリングのところもやる。
だいぶここまで来るとしざが高いところの実装になるって感じですね。
いわゆるアプリケーション固有のロジックであったりとか一般的によく利用される制御的なものをここで担っていく。
これをちゃんとインターフェースとかで配置していくって感じですね。
セッション周りだったりとかアプリケーションサービスとかっていうのでやるところですね。
1個下のさっき言ったドメインサービス層っていうのがドメインサービス。
例えばリポジトリ周りとかになったりするんですかね。
で最後一番外側のレイヤーですね。
インフラストラクチャーそうです。
ここはデータベースとかキャッシングとか外部サービスとかログ出力メッセージングなど外部要素とのやり取りを担うところですね。
ここまで来ると本当にだいぶ外側って感じは確かにあります。
あとデータの映像化もしたりとかデータフェッチングもしたりとか外部サービスとかAPIとかへのリクエストなど
まさにドメインモデルとかアプリケーションサービスの要求を満たす役割ですね。
あとテストとかもやったりするのでここはほぼほぼ何か機器の要件に近いところまでちょっと関わってくるレイヤーと思ってもいいかもしれないですね。
データベースとかオールマッパーもそうですし
さっきのユニットテストとかもそうですし
まあ本当よりコアな実装ではないところをですね
アプリケーションとして最後完成させていく外側のところを担うのは本当にそうだなと思いましたね。
はい、あといろんな記事見てて
オニオアーキテクチャーを利用したクラス設計の例とかを図示してくださっている方もいて
これもすごくわかりやすいんですけど
さすがにこれは口頭で説明するのはちょっと難しいので
まあ皆さんでいろいろ調べていただけたらと思いますけど
あとオニオアーキテクチャーの教義
教義、教える意義の義ですね
教義っていうものがあってジフェリーパレルモシによると
オニオアーキテクチャーの教義として以下を挙げられているっていうのが書いてありまして
ここもちょっと読んでいきたいんですけど
アプリケーションのロジックっていうのは独立したドメインモデルを取り囲むように配置をされています
インフラストラクチャー層と各別の内側の層にインターフェースを定義しておいて
インターフェースを定義した層とは別の外側の層がインターフェースを実装する
09:02
依存性逆転の原則を利用しているため
依存性の方向というのは常に外側の層から内側の層に向かうよという話ですね
アプリケーションコアのロジックっていうのは
インフラストラクチャーを探ししっかり切り離されているっていうのが重要というところでした
なるほどね、外側から内側の方向へのベクトルなんですね
一応そのレイヤードアーキテクチャーと今回のオニオアーキテクチャーの違いとかも若干書かれたりしていて
先ほど出ましたジフェリーパレルモシによると
オニオアーキテクチャーといわゆる伝統的な階層化アーキテクチャー
レイヤードアーキテクチャーの違いっていうのは
階層感の呼び出し方や依存関係にあるよみたいなところの説明がされていて
いわゆる従来の階層化アーキテクチャーっていうものだと
基本的に一つ下の階層に依存すると
UI層がデータアクセス層とかに依存することはないよねみたいな話ですね
それはまあそうですよね
UIから直接データアクセス、データベースとかのやり取りする層にやり取りすることはないですよね
データくれっていうモデルに1回アクセスしておいて
モデルがIOだったりデータアクセスとかになってくれると
それは確かにおっしゃる通りですけど
オニオアーキテクチャーではですね
外側の階層から内側の階層に依存するとき
一つ下以外の内側の階層に対して依存することも可能にしてますと
実際の実装でより柔軟にというか
ケースバイケースでそういうふうな口を作ってるっていうところですね
なるほどでした
でも実際に実装してると
これ本当直でデータベースに直接アクセスして
そのままデータを取りたいみたいなときも
なくはないんですよね
もちろんデータをしっかりごにょって
整形とかしたりキャッシングしたりとかっていうのを
一個上のレイヤーで挟んで
UI側はそこを叩けばいいみたいな話はもちろんあるんですけど
直でデータの整形とかもいらん
とにかくデータくれとか
このパラメータ一つだけ更新したいんで
ポストしたいんだよねみたいな
あったりはしたりするので
多分その辺の話があるんじゃないかとちょっと思ったりはしました
ちょっとそこが厳密な違いがあるんですね
レイヤーと各レイヤーごとで分けられてるんですけど
一つ下のところにしか関心がないというか
アクセスはしないよっていうところが違い性ですね
この辺うまいことやることで
ビジネスドメインの明確な理解だったり
高い柔軟性とか保守性を担保したり
あとはレイヤーとか抽象化をしっかりすることによって
テストの良い性ですね
テスタブルにコードを書くことができるというので
ここも結構強いところですね
その辺を分けてビジネス要件をしっかり満たすという感じですね
そもそもオブジェクト思考っていうのは
現実世界というものをいかにプログラムとか
コードに落とし込むみたいな概念からスタートしてるはずなので
それをよりいろんなアーキテクチャとか設計方法で表現をする
というのの一つがこういうオニオンアーキテクチャという手法ですね
というところでした
記事自体はこの辺で止まることがほとんどですね
他のいろんな記事も読みましたけど
基本的には説明本とそんなところですね
軽くそれぞれの層の説明だけをしてあって
あとはそれを現場で実際に使ってくださいみたいな話でしたね
やっぱ面白いですね
アーキテクチャというか設計の話はつくづく読んでて面白いし
現実世界を言語化するって久しぶりにやらないので
12:00
特に僕はフロントエンドばっかりやってるので
UI層のところばっかりしかやらないので
しっかり設計をするってあんま概念ないんですよね
CSSとかのクラス分けとか名前分けするところでの
設計論は確かにあるんですけど
それぐらいしかないのでね
システム全体としての設計をするのは
なんだかんだ自分の頭をフル回転させる感じはありますけど
ブロックとかパズルやってる感覚もちょっとあって
楽しいなっていう感じはありますけど
自分の油断はさておき
実装ですね
やっぱなんだかんだ最後は設計は実際に使ってみて
自分で実装するところまでいかないと
やっぱ身につかないし頭デッカチになりがちなので
しっかり手を動かして学んできたらと思いますし
またなんか書いたら
開発日誌とかよりぼうしとりとか公開したいと思いますので
ボロクソに叩いていただいて構いませんので
ツッコミいただければなと思います
はい今回はこんなところで終わっていきたいと思います
いつも聞いてくださり本当にありがとうございます
ではまた次回の主力でお会いしましょう
バイバイ
