オニオンアーキテクチャを分解してみる

オニオンアーキテクチャを分解して理解してみる 2023/03/26 kondo

自己紹介 C#を日々勉強中！！ 名前 Kondo 経歴 社会人2年目のエンジニア 業務 C# デスクトップアプリ開発 趣味 サッカー、登山、写真などなど その他 犬好き

はじめに オニオンアーキテクチャを調べるとよく見る円形の図が・・・ なるほど。よくわからん！

オニオンアーキテクチャとは オニオンアーキテクチャとは、Jeffrey Palermo氏により考案されたアーキテクチャです。 ※ Jeffrey Palermo氏の参考記事はこちら The Onion Architecture : part 1 | Programming with Palermo (jeffreypalermo.com) これまでの階層化アーキテクチャとオブジェクト指向の考え方を踏襲した上で、ソフトウェアの内部構造を 円環状に分割し、ビジネスドメインのコアロジックを中心に配置したアーキテクチャとなっています。 依存の方向は外側から内側に向かって依存しています。 依存の方向 なるほど。よくわからんけど。 ひとまず階層化アーキとは何が違うのだ？ 円状になって玉ねぎみたいだからオニオンなのか

• https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/

階層化アーキテクチャの問題点？？ 右図のような階層アーキテクチャの場合、上位の階層から下位の階層に 向かって依存します。 UI(プレゼンテーション)層 この場合、上位での変更が生ずると、下位層にも影響があるので、保守 性や柔軟性が低下する可能性がありますね。 ビジネスロジック層 データアクセス層 オニオンアーキテクチャで保守性、柔軟性のUP オニオンアーキテクチャの場合、円形の外側の階層からから中心の階層 に向かって依存するので、右図のように1以下の階層への依存となりま す。 UI層 データアクセス層 ビジネスロジック層 従って、上述のような、上位層(外側の層)の変更が、下位層(内側の層) に影響することなくなり、保守性、柔軟性が高くなるといえますね。 ドメイン層

円の図を分解してみた 円の図では理解が追いつかなかったので、分解してそれぞれの責務を明確にしてみました。 責務： 下位層のIFを実装する。 責務： 外部との入出力を実現 UI層 テスト層 インフラ層 アプリケーションサービス層 ドメインサービス層 責務： ドメイン層が公開する操作を組み合わせ、ユー スケースを実現するイメージ。 アプリケーション固有のロジックが配置される ※クリーンアーキテクチャでは、ユースケース 層とも扱われる。 責務： ビジネスロジックの振る舞い、IF を配置 ドメインモデル層 責務： ビジネスロジックのコアロジック やビジネスルールを表現 Entity, ValueObjectなど

依存性逆転の法則との関係 ここで少し依存性逆転の法則について話します。 依存性逆転とは、 依存性逆転の法則（Dependency Inversion Principle、DIP）は、SOLID原則の一つであり、ロバート・C・マーティ ンによって提唱されました。この原則は、高レベルのモジュールは低レベルのモジュールに依存すべきではな く、どちらも抽象に依存すべきだと述べています。これは、具体的な実装に依存するのではなく、抽象的なイ ンターフェースやクラスに依存することで、ソフトウェアの柔軟性や拡張性を高めることを目的としています。 少しわかりにくいのでざっくりいうと 「重要な部分が、重要でない部分に依存しないよう設計すべし」 といったところでしょうか。 具象に依存するのではなく抽象に依存する事により、依存の方向が逆転するやつだったな

依存性逆転の法則との関係 オニオンアーキテクチャにおいてはこの依存性逆転の原則を実現しています。 オニオンアーキテクチャでは、外側の技術的な詳細から内側のビジネスルールに依存することを避け、代わり にビジネスルールが外部の詳細から分離されるように設計されています。 つまりオニオンアーキテクチャでは、 ドメイン層(内側)におけるビジネスロジックは内側に配置されます。 そして、外側に技術的な詳細やフレームワークに関連する実装が配置されます。 こうすることで、ビジネスロジックが外部から切り離されていますね。 各層が抽象に依存し、具体的な実装に依存しないから、変更や置換が容易になるってことか

具体例とメリット TaskSQL Repository UI層 テスト層 TaskRDB Repository インフラ層 アプリケーションサービス層 Task Application ドメインサービス層 Task Repository ドメインモデル層 Task 上記の例の場合、ドメインサービス層では、TaskRepositoryが実クラスではなく、インターフェースと なっています。 アプリケーションサービス層は、 TaskRepositoryの型を定義しておけば、 永続化先がSQLからRDBに変更になったとしても、他の層は修正の手を加える必要がありませんよね。

オニオンアーキテクチャの利点 ここまで雑多に話をしてきたので、メリットをまとめます。 1. 柔軟性 オニオンアーキテクチャは各層が疎結合になるので、変更が容易になります。 2. 保守性 各層が分離されているため、変更時の他への影響を与えにくく、保守性が向上します。 3. テストの容易性 円の外側から内側に向かって依存しており、疎結合なので、UTや結合テストがしやすくなりますね。 テスト時は、モックやスタブなどを使用して、外部の依存性をシミュレートすることができます。

オニオンアーキテクチャのまとめ 依存の方向 オニオンアーキテクチャとは、 ソフトウェアを円環状に構造化した設計手法である。 内側にはビジネスロジックが、外側には技術的な実装が配置される。 依存性 オニオンアーキテクチャでは、依存性逆転の法則が重視される。 内側のビジネスロジックは、抽象的なIFに依存し、外側には依存しない。 そのため、内側の層は変更に強い！ オニオンアーキテクチャのメリット ・柔軟性 ・保守性 ・テスト容易性 実際にやってみようと思えるくらいには理解できたかも

おわりに ・今回はオニオンアーキテクチャを学習してみました。 • 今後は、この設計手法を用いてアプリケーションなどを設計・実 装したものを共有していきたいと考えております。