Clean Architecture

クリーンアーキテクチャ勉強会資料

Transcript

1. Clean Architecture
2. 本日の流れ  事前準備  クリーンアーキテクチャの基礎を理解  ソフトウェアアークテクチャとは  ソフトウェアアーキテクチャの目的  DDD、ドメインモデリングとは  クリーンアーキテクチャとは  SOLID原則１つずつ解説  どんな原則か  悪いコードを見てみる  修正方針  Q＆Aで理解を深める  ぐちゃぐちゃコードをクリーンなコードにするワーク
3. この勉強会のスタイル  質問はいつでもOK  質問の回答者は誰でもOK  スライドの内容が唯一の正解ではないため、スライドに対し て「こういう考えもあるよ」等あれば、遠慮なくいってください  スタイルとしては講義形式というより、みんなで勉強、教え あうイメージ
4. 質問シート  勉強会中に質問があれば下記の質問シートに記入してください  もちろん口頭での質問でもOKです https://docs.google.com/document/d/1LMYaRrYWNRpPV-QrJY0Pe0chViAlwrLzH1yvB9xQOTM/edit?usp=sharing  質問シートの内容は後半で回答タイムを設けます
5. 事前準備  本日使用するコードを下記のリポジトリからクローンしてください。 https://github.com/rina-hagihara0844/clean-architecture-examples git clone https://github.com/rina-hagihara0844/clean-architecture-examples.git
6. Speaker Profile  株式会社Digeon 2025年6月入社  氏名：萩原里菜(29)  PM兼開発者  仕事で使っている言語：Go、React等  家族：双子の弟・父・母・祖母・19さいのといぷー  趣味：ボードゲーム、旅行、お笑いラジオ、映画  X（Twitter）：@fjwmmlb25  Zenn：https://zenn.dev/h4gi
7. システム全体の「構造」と「設計の基本方針」を示すもの ソフトウェアアーキテクチャとは
8. ソフトウェアアーキテクチャの目的 ソフトウェアアーキテクチャの目的は 求められるシステムを開発・保守するのに必要な人材を最小限にすること Robert C. Martin（著）／角 征典・高木 正弘（訳）．『Clean Architecture 達人に学ぶソフトウェアの構造と設計』．KADOKAWA／ドワンゴ，2018年
9. ソフトウェアアーキテクチャの目的 これまでに複数の文献や事例を参照した結果、「求められるシステムを開発・保守するのに必要な人材を 最小限にする」ためには、以下の要素が特に重要であると考えます。 拡張性 保守性 テスト容易性 可読性
10. ソフトウェアアーキテクチャの目的  拡張性が高い 新しい機能や要件を追加する際に、既存の構造を壊さず最小限の変更で対応できる  保守性が高い 後から変更や修正をしても壊れにくく、理解・修正・拡張がしやすい テスト容易性が高い 各モジュールが独立してテスト可能であり、テストコードが容易に記述・保守できる  可読性が高い 命名や構造、設計ルールが一貫しており、新規開発者でも短期間で理解・参加できる コードの内容や意図が容易に理解できる
11. クリーンアーキテクチャを理解する前に 知っておくと理解しやすい概念  DDD、ドメインモデリングへの理解
12. DDD、ドメインモデリングとは（シンプルに）  ドメインとは ソフトウェアが解決しようとしている、業務の領域のこと  DDD（ドメイン駆動設計）とは ドメインをソフトウェアの中心に添えてシステムを構築する設計手法 ドメイン駆動設計の主な目的は、ビジネスの本質（ドメイン）を深く理解し、それをソフトウェアに適切に反映させる こと  ドメインモデリングとは 業務用語やルールを整理し、エンティティや値オブジェクトに分け、関連や振る舞い（メソッド）を設計すること 基本的に、ドメインエキスパートとエンジニアが一緒に行うことを前提としており、「作ろうとしているシステムについて、ビ ジネスサイドとエンジニアサイドが、共通認識を持ち、意思疎通する」ことを可能にする
13. クリーンアーキテクチャ  Enterprise Business Rules ビジネスルールを表現する層  Application Business Rules ユーザーの行動（ユースケース）を表現する層  Interface Adapters データをユースケースやエンティティで扱える形に変換する層  Frameworks and Drivers データベースやUIなど、外部の技術的な詳細を担当する層
14. クリーンアーキテクチャ  ひとことでいうと 依存の方向性を「より変更されにくい部分」に向けることで、変更や拡張に強くすることができるアーキテクチャ
15. クリーンアーキテクチャ ～メリット～ 最大の目的は、変更コストを最小化し長期的な開発効率を最大化すること  保守性： ビジネスルール（ドメイン）を他の層（UI・DB・外部サービスなど）から独立させることで機能を追加・修正すると きに他の部分への影響を最小限に抑えられる  再利用性・テスト容易性： 依存関係を内側（ビジネスルール）に向けることで、ドメインロジックは外部技術に依存しないため、ビジネスルー ルだけを単体でテストできる 外部要素をモック化・差し替え可能にすることで、自動テストやリファクタリングが容易になる  開発効率： 依存関係の向きを制御できるため、コンポーネントごとにそれぞれのチームが独立して開発できる
16. クリーンアーキテクチャ ～デメリット～  学習コストと理解の負担： 複数の層に分けて設計するため、学習コストや開発の初期段階での工数が増える。
17. クリーンアーキテクチャ～採用基準～  クリーンアーキテクチャの採用基準 クリーンアーキテクチャは 中〜大規模で、長期的に保守するシステム向け の設計です。 特に以下のような場合に効果があります：  UIやDBなどの外部技術が変わる可能性が高い  ビジネスロジックを長く使い続けたい・他プロジェクトでも再利用したい  テストをしっかり行いたい  不向きなケース  小規模・短期開発・PoCなど
18. 「変更に強いソフトウェア設計」を行うコツとしてRobert C. Martin という開発者が提唱した5つの原則  単一責任の原則：Single Responsibility Principle  オープン・クローズドの原則：Open-Closed Principle  リスコフの置換原則：Liskov Substitution Principle  インターフェイス分離の原則：Interface Segregation Principle  依存関係逆転の原則：Dependency Inversion Principle それぞれの頭文字を一文字ずつとって、SOLID原則とよばれる SOLID原則
19. 単一責任の原則 Single Responsibility Principle
20. SRP：単一責任の原則〜どんな原則か〜  クラスやモジュールが持つべき責任を1つに限定する原則 ※モジュールとは、一つのまとまった責務を持つ単位 言語や設計レベルによって指す対象は異なりますが、SOLIDはオブジェクト指向設計原則なので、主にクラス やコンポーネント（機能単位）を指す
21.  新しい機能を追加・修正する際に、関係のない部分まで影響を受けてしまい、他の機能が壊れるリ スクが高まる  複数の役割が混在し、コードの再利用が難しくなる  テスト対象の範囲が広がり、特定の処理だけをテストすることが難しくなる  クラスや関数が肥大化して意図が不明瞭になり、可読性が低下する SRP：単一責任の原則〜従わないとどうなるか〜 単一責任原則で無責任な多目的クラスを爆殺する #設計 - Qiita
22. オープンクローズドの原則 Open-Closed Principle
23. OCP：オープン・クローズドの原則〜どんな原則か〜 ソフトウェアの構成要素は拡張に対して開いていて、修正に対して閉じていなければならない  オープン： 変更があった場合にも素早く柔軟に対応できるように、あらかじめ変更しやすい設計にしておく  クローズド : 既存のコードが正常に機能している場合、変更があった場合に既存のコードをなるべく触らなくてよいような 設計をするべき
24.  新しい機能を追加するたびに既存コードを書き換える必要が生じる  変更が他の動作を壊すリスクが高まり、影響範囲が読みにくくなる  差し替え・再利用が困難になる 一言で言うとOCPを守らないと、追加が破壊的変更になり、開発がどんどん辛くなる OCP：オープン・クローズドの原則〜従わないとどうなるか〜
25. 次は、オープン・クローズドの原則のルールを全く守っていないコードを見て、なにが問題か考えてみましょう clean-architecture-examplesリポジトリの/bad/server_bad.goを見てください ※注意：他のファイルにはこの後のワークの答えが紛れているので見ないようにしてください
26. 悪いコードのシナリオ  このコードは従業員が有給（休暇）申請をするAPIのシナリオです  入社から半年経過している従業員だけが申請できる  年度（4/1開始）で年間5回まで申請可能  ルールを満たせば申請が登録され、上長に通知される
27.  抽象化がなく、実装（DBやメールドライバ）を直呼びしている 新しい実装を「追加」ではなく既存コードの「改変」でしか対応できない → 安定しているコードにまで影響が及び、修正が連鎖しやすい構造になっている →このままでは既存コード改修時に、既存経路すべての再テストが必要になる OCP：オープン・クローズドの原則〜悪いコードは何がダメか〜
28.  Notifier インターフェース＝「拡張の入口」を設ける 外部の処理（DBやメール）を直書きするのではなく抽象化する OCP：オープン・クローズドの原則〜修正方針〜
29.  UseCaseは抽象に依存させる（差し替え自由） 通知手段が何個あっても Notifiers 配列に入れておけば全部呼ばれる。 OCP：オープン・クローズドの原則〜修正方針〜
30.  新しい通知手段は“追加”だけで対応できる 新しい通知手段を追加したい場合は既存は一切触らず新しい型（Notifier実装）を追加するだけ OCP：オープン・クローズドの原則〜修正方針〜
31. リスコフ置換原則 Liskov Substitution Principle
32. LSP：リスコフ置換原則〜どんな原則か〜 サブタイプ（子クラス）は、スーパータイプ（親クラス）として問題なく置き換えて使えるべき  事前条件を、派生型で強めることはできない。派生型では同じか弱められる。  事後条件を、派生型で弱めることはできない。派生型では同じか強められる。  不変条件は、派生型でも保護されねばならない。派生型でそのまま維持される。  基底型の例外から派生した例外を除いては、派生型で独自の例外を投げてはならない。 事前条件・・・メソッドを呼び出す前に、呼び出し側が満たしておくべき条件 事後条件・・・メソッドの実行が終わったあとに、呼び出し側に対して保証される状態
33.  事前条件を、派生型で強めることはできない。派生型では同じか弱められる。 もし「支払処理サービス」が「金額がJPYで0円以上なら支払える」としているなら、 派生クラスの「クレジット決済サービス」は「金額が1,000円以上でないと支払えない」と制限してはいけない。 OKな例：クレジット決済サービスは「JPY に加えて USD も可」と許容を広げる  事後条件を、派生型で弱めることはできない。派生型では同じか強められる。 もし「ユーザー登録サービス」が「登録成功時にメールを送る」としているなら、派生クラスの「特別会員登録サービ ス」は「メールは後で送る」としてはいけない。 OKな例：特別会員登録では、登録後にメール＋SMSも送ると保証を強めてもいい。 LSP：リスコフ置換原則〜例で解説〜
34.  不変条件は、派生型でも保護されねばならない。派生型でそのまま維持される。 もし「人」が「年齢は常に 0 以上」 という不変条件を持っているなら、派生クラスの「ティーン」が「年齢は 13〜19 の間でなければならない」と制限を強くしてしまってはいけない。 → 不変条件（Age ≥ 0）は、派生型でもそのまま維持されなければならない。  基底型の例外から派生した例外を除いては、派生型で独自の例外を投げてはならない。 もし「ファイル読み込み処理」がFileNotFoundError だけを投げる と契約されているなら、派生クラスの「画像ファ イル読み込み処理」がImageFormatError といった 新しい例外 を投げてしまってはいけない。 → 利用側は「FileNotFoundError だけ来る」と思っているため、新しい例外が来ると正しく扱えなくなる。 LSP：リスコフ置換原則〜例で解説〜
35.  置き換え可能性が失われ、差し替えや拡張時に既存コードが壊れやすくなる → 「型の契約」が守られないため、LSP違反はそのまま OCP違反 を引き起こす  利用する側が実装ごとの例外処理や分岐を持たされる → 戻り値や挙動が統一されていないので、条件分岐だらけのコード が生まれる LSP：リスコフ置換原則〜従わないとどうなるか〜
36. インターフェース分離の原則 Interface Segregation Principle
37. ISP：インターフェース分離の原則〜どんな原則か〜  クライアントが利用しないメソッドへの依存を強制してはならない 「インターフェース継承先で使わないメソッドがないようにインターフェースをわけよう」ということ ※「クライアント」 は、そのインターフェースを使う側＝利用コード
38.  本来不要なメソッドを実装・理解する義務が生まれ、コードが読みにくくなり、保守コストが増える  インターフェースに手を入れるたびに、使っていない側まで影響が波及する → 破壊的変更を招きやすい  モックを用意する際にも「使わないメソッド」までモックしなければならず、テストが肥大化し、意図が不明瞭にな る  無関係な責務が混ざっているため、コンポーネント単位での再利用が困難になる ISP：インターフェース分離の原則〜従わないとどうなるか〜
39. 次は、インターフェース分離の原則のルールを全く守っていないコードを見て、なにが問題か考えてみましょう clean-architecture-examplesリポジトリの/bad/isp/isp_violation.goを見てください ※注意：他のファイルにはこの後のワークの答えが紛れているので見ないようにしてください
40. 実装側が使用していないメソッドにまで、依存しているのでISP違反である  インターフェースに不要なメソッドが含まれているため、それらを実装する必要がある →インターフェースの１メソッドを修正するだけで、関係のない実装まで修正する必要があり、無駄なデプロイも発 生する ISP：インターフェース分離の原則〜悪いコードは何がダメか〜
41.  インターフェースを責務ごとに小さく分離  クライアントは複数のインターフェースに依存してもよいので 「必要なものだけ」を組み合わせて使う ISP：インターフェース分離の原則〜修正方針〜
42. ISP：インターフェース分離の原則〜修正方針〜
43. 依存性逆転の原則 Dependency Inversion Principle
44. DIP：依存性逆転の原則〜どんな原則か〜  上位のモジュールは下位のモジュールに依存してはならない 内側（ビジネスルール）は外側を知らない状態でなければならない  上位モジュール： 内側のドメイン(ビジネスモデルなど)をさす  下位モジュール： 外側の上位モジュールの実装の詳細をさす
45.  DBなどの下位モジュールを変えるだけで、ビジネスロジックの修正が必要になる つまり下位の詳細変更が上位のビジネスルールに変更を要す  具象に直接依存するとユニットテスト時にモック・スタブ注入がしづらく、テストが重くなったり、不安定な外部 依存に引きずられるリスクがある DIP：依存性逆転の原則〜従わないとどうなるか〜
46. 次は、依存性逆転の原則のルールを全く守っていないコードを見て、なにが問題か考えてみましょう clean-architecture-examplesリポジトリの/bad/server_bad.goを見てください ※注意：他のファイルにはこの後のワークの答えが紛れているので見ないようにしてください
47. 悪いコードのシナリオ  このコードは従業員が有給（休暇）申請をするAPIのシナリオです  入社から半年経過している従業員だけが申請できる  年度（4/1開始）で年間5回まで申請可能  ルールを満たせば申請が登録され、上長に通知される
48.  上位層が下位層の実装に依存している ビジネスロジックがdatabase/sqlやsendSMTPを直接操作しており、依存の向きが逆  インターフェースがなく、外部依存をモック化できずユニットテスト不能  高結合でモジュール性が低い 一部を変えると他まで影響し、再利用や保守がしづらい ※モジュール性とは、部品同士が独立して、変更や再利用がしやすい性質 DIP：依存性逆転の原則〜悪いコードは何がダメか〜
49.  インターフェースを定義する：EmployeeRepo, LeaveRequestRepo, Notifier, Clock など →上位層（ビジネスロジック）が下位層（DB・SMTPなど）に依存している構造を解消する  ユースケースがインターフェースに依存するようにする  実装側でインターフェースを実装する  main.goで依存注入（コンポジションルートとして全層を組み立て） ※コンポジションルート・・・アプリケーション全体の依存関係を「組み立てる（compose）」場所のこと DIP：依存性逆転の原則 〜修正方針〜
50.  各レイヤーが自分で依存するもの（DBやメール送信など）を作らず、外から与えてもらう仕組みのことで す →これにより、各レイヤーは自分の責務に集中でき、ハードコーディングされた依存関係を避けられます たとえば、ユースケース層が必要とするリポジトリや通知機能を、引数やコンストラクタ経由で「注入」します DIP：依存性逆転の原則〜依存注入（DI）とは〜
51. DIP：依存性逆転の原則〜依存注入（DI）とは〜
52. DIP：依存性逆転の原則〜依存注入（DI）とは〜
53. DIP：依存性逆転の原則〜依存注入（DI）とは〜
54. DIP：依存性逆転の原則〜依存注入（DI）とは〜
55. 質問タイム クリーンアーキテクチャに関する質問にわが社のエンジニアが答えてくれます。 https://docs.google.com/document/d/1LMYaRrYWNRpPV- QrJY0Pe0chViAlwrLzH1yvB9xQOTM/edit?usp=sharing
56. ワークタイム ２〜３人１チームになって、SOLIDの理解のために使っていた汚い コードをクリーンなコードにしてください このワークは本日学んだことを復習し、今後実践で使えるようにするこ とを目的としています クリーンなコードを完成させる必要はなく、理解を深めるためなら方法 は何でもいいです
57. 下記の点を話し合ってみてください  ソフトウェアアーキテクチャの目的「求められるシステムを開発・保 守するのに必要な人材を最小限にする」ということを考えた上で 汚いコードはなにがだめなのか  修正前と修正後ではなにが変わり、どんなメリットがあるのか  クリーンなコードにするために業務で意識してやっていること チームで話したことで、シェアしてもいいものがあれば下記にてシェアし てください https://docs.google.com/document/d/1FEU3grQJ0ceBuzDzlaK8Pi p2BNLB3dtFJdlcgCc15jg/edit?usp=sharing ワークタイム
58. 採用情報 株式会社Digeonでは現在、 一緒に働く仲間を募集しています 興味がある方は公式ウェブサイトまたはwantedly、萩原に直接 ご連絡いずれの方法でも構いませんので、一度ご連絡ください。 その他技術記事や、ブログ等も興味あれば読んでみてください。 採用ページ：https://digeon.co/jobs Wantedly:株式会社Digeonの会社情報 - Wantedly X（Twitter）：https://x.com/Digeon_inc Zenn：株式会社Digeon | Zenn Note：株式会社Digeon｜note スピーカー記事：挑戦と成長を後押しする環境がここに。 萩原さん・柴田さんインタビュー｜株式会社Digeon
59. 参考記事 ドメインモデリング https://products.sint.co.jp/ober/blog/ddd https://zenn.dev/m10maeda/articles/i-had-domain-driven-design-down-pat ヘキサゴナルアーキテクチャ https://zenn.dev/heyyou/articles/f380adb8d1fe8f https://qiita.com/cocoa-maemae/items/b08c4cf95d47e314e2dc https://www.issoh.co.jp/tech/details/2965/#i-2 オニオンアーキテクチャ https://qiita.com/cocoa-maemae/items/e3f2eabbe0877c2af8d0 https://qiita.com/GleapPost/items/d58b309315effb0e9515 [DDD]ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か #Java - Qiita クリーンアーキテクチャ https://zenn.dev/sre_holdings/articles/a57f088e9ca07d https://www.geeksforgeeks.org/system-design/complete-guide-to-clean-architecture/?utm_source=chatgpt.com https://tech.anycloud.co.jp/articles/clean-architecture/
60. 参考記事 SOLIDの原則 https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design?utm_source=chatgpt.com https://zenn.dev/k_ichirof/articles/d79ad8153eabf7 単一責任の原則 https://www.geeksforgeeks.org/system-design/complete-guide-to-clean-architecture/?utm_source=chatgpt.com https://dev.to/the_architect/clean-architecture-for-enterprise-applications-a-practical-guide-from-the-trenches-3ii0?utm_source=chatgpt.com https://www.geeksforgeeks.org/system-design/complete-guide-to-clean-architecture/?utm_source=chatgpt.com リスコフの原則 https://qiita.com/yuki153/items/142d0d7a556cab787fad 【SOLID】リスコフの置換原則を完全に理解したい #C# - Qiita インターフェース分離の原則 https://zenn.dev/andmorefine/articles/5ae927efe2daba https://qiita.com/k2491p/items/7b4e56789964ac6328b3 依存性逆転の還俗 https://qiita.com/nozomi2025/items/39a1ab432aa7c91bd5df?utm_source=chatgpt.com https://zenn.dev/purenium/articles/clean-architecture-essence?utm_source=chatgpt.com
61. Clean Architecture以外の Architecture紹介
62. レイヤードアーキテクチャ  プレゼンテーション層：ユーザーとのやり取りを担当 UI、APIエンドポイント、リクエスト処理など  アプリケーション層：ユースケースの制御・業務フローを管理 ユースケースサービス、トランザクション管理など  ドメイン層：ビジネスロジックやルールを表現 エンティティ、値オブジェクト、ドメインサービスなど  インフラ層：永続化や外部システムとの通信を担当 DBアクセス、APIクライアントなど
63. レイヤードアーキテクチャ  メインの概念 システムを責務ごとに「層」に分け、上位層が下位層に依存する構造。 典型的には「プレゼンテーション層 → アプリケーション層 → ドメイン層 → インフラ層」。  メリット 責務の分離により保守性・拡張性が高い 各層ごとにテストが容易 チーム開発時の分担がしやすい 層という一貫した共通のルールがあることで学習コストが低く済む  デメリット ドメインロジックが外部技術に依存してしまう
64. ヘキサゴナルアーキテクチャ （Ports & Adaptersアーキテクチャ）  ドメイン（内側）：変わらない本質（ビジネスルール）  アプリケーション・コア（内側寄り）：ユースケースの制御（フロー管理）  ポート（外側）：ドメインが外の世界とやり取りするためのインターフェース 多くのアプリではユーザー側のポートとDB側のポート２種類を持つ  アダプタ（外側）：外部をポートに合わせて変換する実装 Inbound Adapter・・・ UIやAPIなど「ドメインを呼び出す側」 Outbound Adapter・・・ DBや外部APIなど「ドメインに呼ばれる側」
65. ヘキサゴナルアーキテクチャ  メインの概念 システムのコアであるビジネスロジックと、それを取り巻くインターフェース（ポート）およびその実装（アダプター） に分離すること これにより、アプリケーションのコアは外部の詳細に依存せず、テストが容易になり、外部要素の変更や追加にも 柔軟に対応できるようになる
66. ヘキサゴナルアーキテクチャ  メリット ビジネスロジックが外部技術から 隔離 されているため、変更の影響範囲を小さくできる 内部ロジックに対して モックを使ったユニットテストが容易になる 外部技術の差し替えを容易にできる  デメリット ポート・アダプタの抽象化が過度になると、コードが冗長化したり、理解コストが上がる。
67. オニオンアーキテクチャ  ドメインモデル層：アプリケーションのビジネスドメインを表現 Entity, ValueObjectなど  ドメインサービス層：ビジネスロジックを記述する層 Repositoryインターフェース、ビジネスルール、ドメイン固有のロジック  アプリケーションサービス層：ユースケースを表現 ドメインサービスのインターフェースを順次呼び出す  インフラストラクチャー層：外部システムとの連携を担当 Repositoryの実装クラス、外部API、データベースへのアクセス  プレゼンテーション層：APIのリクエスト・レスポンスに責任を持つ 入力値の検証とドメインモデルへの変換する
68. オニオンアーキテクチャ  メインの概念 オニオンアーキテクチャの核心は、DomainとInfrastructureの依存関係を逆転させることで、 全ての依存関係は円の中心の層に対して向かう。 保守性、テスト容易性、依存性の点で優れたアプリケーションを構築することを目的としている。
69. オニオンアーキテクチャ  メリット 保守性: 外部技術変更がビジネスロジックに影響しない テスト容易性: インターフェースによりモックが容易 拡張性: 新しい外部システムの追加が容易  デメリット 初期の学習コストが高い 短期プロジェクトにはオーバースペック
70. 「ヘキサゴナル、オニオン、クリーン」の3つは、依存方向は常に「内側」へ向かうという点で同じ → ドメインモデル（ビジネスルール）が中心で、そこに依存するのは外側の層。