忙しい人のためのClean Architecture

Transcript

1. #codepolaris
   Clean Architectureって何？っていうの
   を開発者たちが考えてみた

   yuriemori
   しの
   ねこさいん
   

   View Slide

2. #codepolaris
   Clean Architecture（本）の紹介

   Robert C. Martin
   色んなソフトウェア設計原則を提唱したりアジャイル開発宣言の創設に
   携わった人。通称Uncle Bob
   Clean Architecutureはボブおじさんのエンジニア人生で辿り着いた
   ”いい感じのアーキテクチャ”とはどういうものか、って話。
   

   View Slide

3. #codepolaris
   今日は何を話すのか

   ● Clean Architectureを読み終わって、本読んだり議論したり実際に実装したりしてみ
   ながらなんとなく「こういうもの」というのがわかったので要点をお話します（詳細は
   次のAgendaのスライドに！）。
   ● 「そんなんクリーンアーキテクチャじゃない！解釈違いじゃ！」って意見も大歓迎で
   す（でもお手柔らかにお願いします）。
   

   View Slide

4. #codepolaris
   Agenda

   ● チームメンバー紹介
   ● Clean Architectureって結局何なの？
   ● あるあるな誤解
   ○ Clean Architecture≠あのドーナツのアーキテクチャモデル
   ○ Clean Architecture≠SOLID
   ● Clean Architecture的に考える幸福度の高い実装
   ○ SOLIDの話
   ○ JavaのSpringフレームワークを使った SOLIDの実装（live coding）by しのさん
   ● Agile/DevOpsから考えるClean Architecture
   ○ DevOpsから考えるClean Architecture
   ○ Agileとアーキテクチャ
   

   View Slide

5. #codepolaris
   チームメンバーの紹介

   

   View Slide

6. #codepolaris
   ● Software [email protected] Jappan
   ● C#, Azure, .Netなどなど
   ● 今のPJではSitecoreというCMSを使った設計、開発をやってます
   ● Agile/DevOps
   ● Azure DevOpsを使ったスクラムの実践やチーム開発環境の構築
   ・運用をテーマに登壇したりしてます
   今までの登壇資料はコチラ
   森　友梨映（Yurie Mori）
   @1115_lilium
   https://www.linkedin.com/in/yurie-mori-15392a1bb/
   

   View Slide

7. #codepolaris
   自己紹介

   名前:しの
   ● 金融系の会社でJavaエンジニア5年目 (Java大好き)
   ● 結婚後に大学に入りなおしてエンジニアになる
   ● 輪読会中に妊娠→育休→仕事復帰
   ● あまり頑張りすぎないをモットーに、
   ゆるゆるエンジニアを楽しんでいます
   ● 趣味はボードゲーム
   輪読会中の様子
   生Uncle Bob
   

   View Slide

8. #codepolaris
   自己紹介

   名前：ねこさいん
   ● 薬学生→エンジニア (予定)
   ● 普段はPythonを使っている
   ● 好物：お刺身とコーヒーと紅茶
   ● 趣味：最近スプラ3にハマっている
   ● 一言：クリーンアーキテクチャどころか
   　　「オブジェクト指向なにそれおいしいの」
   　　　状態でしたが、
   　　　居心地がよかったので居座りました。
   ○ 競技プログラミング (AtCoder)
   ○ 研究 (薬のもとになる物質探し )
   ○ 学生ハッカソン、ISUCON等参加
   

   View Slide

9. #codepolaris
   Clean Architectureって結局何なの？

   

   View Slide

10. #codepolaris
    アーキテクチャ
    というかそもそもアーキテクチャって何

    クラス（ソースコードレベルでのモジュール）>
    < コンポーネント
    （デプロイの単位。.Netのdll, Javaの.jar）
    < アーキテクチャ
    コンポーネント
    クラス
    

    View Slide

11. #codepolaris
    アーキテクチャは何のために？

    アーキテクチャの形状の目的は、そこに含まれるソフトウェアの開発・デプロイ・運用・保守を容易にすることで
    ある。
    アーキテクチャの主な目的は、システムのライフタイムをサポートすることである。優れたアーキテクチャがあれ
    ば、システムを容易に理解・開発・保守・デプロイできる。最終的な目的は、システムのライフタイムコストを最小
    限に抑え、プログラマの生産性を最大にすることである。
    （第13章 アーキテクチャとは？）
    

    View Slide

12. #codepolaris
    ソフトウェアの人生

    アーキテクチャの主な目的は、 システムのライフタイム をサポートすることである。
    ライフタイム=寿命
    ソフトウェアの人生：
    開発（設計・実装）→テスト→デプロイ→リリース→運用・保守
    いいアーキテクチャ =開発しやすい、テストしやすい、デプロイしやすい、運用・保守しやすい
    →ソフトウェア開発の全てのライフサイクルで幸せになれるようなアーキテクチャ
    

    View Slide

13. #codepolaris
    どうしたら幸せになれる？

    開発（設計・実装）→テスト→デプロイ→リリース→運用・保守
    よい設計をするための指標
    ・SOLID
    よい実装をするための指標：
    ・KISS(Keep It Short, Simple)
    ・ YAGNI(Your Ain’t Going to Need It)
    ・ DRY(Don’t Repeat Yourserf)
    ・ よい命名 etc.
    デプロイが容易な単位に
    コンポーネント化されている
    ・再利用・リリース等価の原則
    ・閉鎖性共通の原則
    ・全再利用の原則 etc.
    ・依存関係があんまりない
    ・デプロイ、リリース作業自体が
    簡単
    ・デプロイ、リリース作業後に事
    故らない
    ・どこを直せばいいかすぐわかる
    ・修正する時に他への影響範囲が少
    ない
    ・機能追加しやすい
    ・テストが簡単
    ・テストの範囲はできるだけ狭い
    方が嬉しい
    ・適切にモジュール分けされている
    

    View Slide

14. #codepolaris
    まとめ

    クリーンアーキテクチャ= ソフトウェアライフサイクルを通して幸福度高く開発、デプロイ、
    保守、運用しやすいアーキテクチャ
    

    View Slide

15. #codepolaris
    ありそうな誤解

    

    View Slide

16. #codepolaris
    このドーナツの図 ≒ クリーンアーキテクチャ

    

    View Slide

17. #codepolaris
    ● ソフトウェアを開発する上で一番重要な
    のはビジネスルール（Entity）で、DBとか
    UIとかデバイス、それとビジネスロジック
    とのインターフェイス はソフトウェアの
    「外」の要素だから、それに依存してはい
    けない
    ● Entityとそれより外部にある要素は制御
    の流れと依存関係が適切に分離されて
    いるべき
    これはEntityとそれに関係ない外部の要素
    を切り分けて依存関係を分離せよ、と言って
    いて、この図=クリーンアーキテクチャのモ
    デルそのものではない
    

    View Slide

18. #codepolaris
    決定を遅らせる

    ソフトウェアアーキテクチャとは、境界線を引く技芸である。（中略）ソフトウェアの要素を分離し、お互
    いのことがわからないように制限するというものである。
    逆に、なかなか境界線を引かないこともある。初期に境界線を引くのは、
    決定をできるだけ遅らせる
    ためである。決定によってビジネスロジックが汚染されないようにしているのだ。
    アーキテクトの目的は、求められるシステムを構築・維持するために必要な人材を最小限に抑えるこ
    とである。こうした人々のパワーを奪うものは何か？そ
    れは結合である。それも早すぎる決定との結
    合である。
    早すぎる決定とはどのようなものか？それは、
    システムのビジネス要件（ユースケース）と関係のない
    決定である。たとえば、フレームワーク、データベース、ウェブサーバー、ユーティリティライブラリ、
    DI
    などに関する決定が含まれる。
    

    View Slide

19. #codepolaris
    SOLID≒クリーンアーキテクチャ

    ● SOLIDの前にアーキテクチャの構成を思い出してみよう
    ● クラス（ソースコードレベルでのモジュール）< コンポーネント（デプロイの単位。.Net
    のdll, Javaの.jar）< アーキテクチャ
    ● SOLIDはあくまでもシステムのクラスの設計でよい設計をサポートするもの
    

    View Slide

20. #codepolaris
    まとめ

    あのドーナツの図で言いたいこと=本質的な部分（ビジネスロジック）はそれ以外の要素
    （フレームワーク, DB, UI）に依存するような設計をしてはいけない
    →DBとかフレームワークとかUIとかを先に決めると後々身動きができなくなる
    SOLIDはあくまでもクラスのレイヤーで考慮すべきもの。
    

    View Slide

21. #codepolaris
    SOLIDの基本

    

    View Slide

22. #codepolaris
    SOLIDとは

    

    ボブおじさんが考えたクリーンアーキテクチャの為のガイドライン
    これに沿って開発したらいい感じにクリーンアーキテクチャの思想に沿った開発ができる
    

    View Slide

23. #codepolaris
    SOLID原則

    
 項目 意味 英語
    S 単一責任の原則 (SRP:Single Responsibility Principle)
    O オープン・クローズドの原則 (OCP:Open-Closed Principle)
    L リスコフの置換原則 (LSP:Liskov Substitution Principle)
    I インターフェイス分離の原則 (ISP:Interface Segregation Principle)
    D 依存関係逆転の原則 (DIP:Dependency Inversion Principle)
    

    View Slide

24. #codepolaris
    S:単一責任の原則

    (SRP:Single Responsibility Principle)

    There should never be more than one reason for a class to change.
    （→変更するための理由が、一つのクラスに対して一つ以上あってはならない）
    一つのクラスは一つの機能のみを担当する
    

    View Slide

25. #codepolaris
    O:オープン・クローズドの原則 (OCP:Open-Closed Principle)

    software entities (classes, modules, functions, etc.) should be open for extension,
    but closed for modification.
    （→ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれている
    べきであり、修正に対して閉じていなければならない）
    ある機能の追加などがある場合、既存のコードを変更せずにその機能の追加(拡張)が
    出来るように設計をするべし
    

    View Slide

26. #codepolaris
    L:リスコフの置換原則 

    (LSP:Liskov Substitution Principle)

    Functions that use pointers or references to base classes must be able to use
    objects of derived classes without knowing it.
    （→ある親クラスへのポインタないし参照を扱っている関数群は、その子クラスのオブ
    ジェクトの詳細を知らなくても扱えるようにしなければならない）
    サブタイプ(S)とスーパータイプ(T)は「S is a T」の原則にのっとり、置換可能である
    

    View Slide

27. #codepolaris
    I:インターフェイス分離の原則

    (ISP:Interface Segregation Principle)

    Many client-specific interfaces are better than one general-purpose interface.
    （→汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェース
    がたくさんあった方がよい）
    クライアントが、自分の必要な要素だけを継承できるするようにするべき
    一つのインターフェースに沢山の要素が入っていると、あるクライエントにとっては必要
    のないものが継承されるということが起きるから
    

    View Slide

28. #codepolaris
    D:依存関係逆転の原則

    (DIP:Dependency Inversion Principle)

    High-level modules should not import anything from low-level modules. Both
    should depend on abstractions (e.g., interfaces), [not] concretions.
    （→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方と
    も具象ではなく、抽象（インターフェースなど）に依存するべきである）
    外側のクラスが内側のクラスに依存するようなことはしてはいけない
    (インターフェースを経由すると、依存関係を断ち切ることが出来るのでこの本で推奨さ
    れているが、アノテーションを使うことでも回避できる)
    

    View Slide

29. #codepolaris
    クリーンアーキテクチャ的に考える

    幸福度の高い実装

    

    View Slide

30. #codepolaris
    Javaのコードを介して実際に見てみよう

    Javaのannotationやデザインパターンを使ってクリーンアーキテクチャの思想に則った
    コードを実装してみる
    

    使用するフレームワーク
    ● Spring Framework
    ● Lombok
    ● JPA/Hibernate
    

    View Slide

31. #codepolaris
    今回のテーマ

    1. アカウントの開設
    ○ 違うタイプのアカウントが開設できる
    2. 預金
    ○ BankCode,BankBranch, AccountNumberでアカウントの特定をする
    ○ 預金できるアカウントとできないアカウントがある
    ■ BasicAccountとSavingAccountは預金ができる
    ■ SuperSavingAccountは預金が出来ない
    オンライン銀行口座サイトを実装せよ！
    

    View Slide

32. #codepolaris
    annotation(アノテーション)ってそもそも何？

    処理系に伝達したい付加的な情報(メタデータ)を注記する
    「ここはこういう役割」「こういう処理をしてね」ということをコンパイル中や実行中にコン
    ピューターに伝えることができる
    基本、@....　という形でメタデータを使用したい場所にくっつけることで使える
    例: @Controllerのアノテーションを付けると、そのクラスはWebサービスになり、外部と
    の接続が可能になる
    

    View Slide

33. #codepolaris
    どんなデザインパターンを使う？

    ❖ DTO (Data Transfer Object) とVO (Value Object)
    ➢ データ受け渡しの為のクラス
    ➢ DTOがエコバッグ的な存在、 VOが段ボールで蓋された荷物的な存在
    ❖ Factory Pattern
    ➢ フレキシブルにインスタンスの生成をするためのデザインパターン
    ➢ インスタンスの生成をファクトリー (=工場)に任せる
    ❖ Builder Pattern
    ➢ インスタンスの生成をコンストラクターに頼らずに出来る
    ➢ 将来attributeが増えていっても、今あるインスタンス生成の為のコードは壊れずに使える
    

    View Slide

34. #codepolaris
    Spring とは

    Javaでよく使われる基本のWEBフレームワーク　(https://spring.io)
    MVCでの開発や、依存性注入(dependency injection)、セキュリティなど、ありとあらゆ
    る事が簡単に出来る
    

    View Slide

35. #codepolaris
    Lombokとは

    形式上省くことが難しいけどあると冗長になるコード(ボイラープレートコード)を省くことが
    できる
    ● getter/setter
    ● constructor
    ● toString
    ● builder
    etc…
    

    View Slide

36. #codepolaris
    Hibernate (JPA)とは

    オブジェクトとリレーショナルデータベース(RDB)の相互変換を行うマッパー
    オブジェクトとテーブルのマッピングを行ってくれる
    -> DAOの実装に関してのデータベースの種類への依存がなくなる
    

    View Slide

37. #codepolaris
    Controllerで使われるannotation

    Controllerは外部との接続を担当
    リクエストを受け取って、レスポンスを返す (基本はクラスをJSONに変換したものが返さ
    れる)
    ❖ @Controller, @RestController
    ➢ そのクラスはWebサービスになり、外部との接続を行う
    ❖ @RequestMapping(“/bankAccount”)
    ➢ http://localhost:8080/bankAccount で接続が出来るようになる
    ❖ @PostMapping, @GetMapping, @PutMapping etc…
    ➢ RequestMappingの、http メソッドを指定
    

    View Slide

38. #codepolaris
    各クラスの役割

    ● BankAccount
    ○ BasicAccount や SavingAccount の親クラス
    ● BankAccountRepository (@Repository)
    ○ DBへの接続
    ● BankAccountController (@Controller)
    ○ 外部への接続
    ● BankAccountService (@Service)
    ○ ビジネスロジック (仲介業者的な)
    

    View Slide

39. #codepolaris
    今回のテーマ

    1. アカウントの開設
    ○ 違うタイプのアカウントが開設できる
    2. 預金
    ○ BankCode,BankBranch, AccountNumberでアカウントの特定をする
    ○ 預金できるアカウントとできないアカウントがある
    ■ BasicAccountとSavingAccountは預金ができる
    ■ SuperSavingAccountは預金が出来ない
    オンライン銀行口座サイトを実装せよ！
    

    View Slide

40. #codepolaris
    復習

    ❖ BankAccount とBasicAccount, SavingAccountは置換可能である
    ➢ リスコフの置換原則
    ❖ Repository, Controller, Service, Factory などでそれぞれ一つのことを担当
    ➢ 単一責任の原則
    ❖ Depositableを継承するのはdepositのメソッドが必要なクラスのみ
    ➢ インターフェース分離の原則
    ❖ FactoryやBuilderのデザインパターン
    ➢ オープンクローズドの原則
    ❖ @Autowiredを使って、上位モジュールでの直接のインスタンス生成を避ける
    ➢ 依存性逆転の原則
    

    View Slide

41. #codepolaris
    まとめ

    フレームワークの想定している使い方をすれば、自動的にSOLIDに対応される
    なのでそこまで難しく考えなくていい
    Spring のフレームワークはめっちゃ優秀なので、フレームワークの勉強はしっかりしま
    しょう
    フレームワークでカバーしきれない部分(リスコフの置換原則とかインターフェース分離
    の原則とか)もあるので、SOLIDを意識しておくと、綺麗なコードになる
    

    View Slide

42. #codepolaris
    Agile/DevOpsから考える

    クリーンアーキテクチャ

    

    View Slide

43. #codepolaris
    DevOpsから考えるClean Architecture

    

    View Slide

44. #codepolaris
    ソフトウェアの人生とDevOps

    ● 開発(Devs)と運用(Ops)がコラボして無駄のない(Lean)ソフトウェア開発をしようね
    というカルチャー、思想
    ● DevOps=開発、運用、品質保証の集合
    開発（設計・実装）→テスト→デプロイ→リリース→運用・保守
    この辺ぐらいがDevの領域 この辺ぐらいがOpsの領域
    

    View Slide

45. #codepolaris
    思い出して、アーキテクチャとは？アーキテクチャの目的は？

    ● アーキテクチャの主な目的は、 システムのライフタイムをサポートすること である。優れたアーキテクチャ
    があれば、システムを容易に理解・開発・保守・デプロイできる。
    ● 作ったら（開発が終わったら） デプロイして、リリースして、リリースした後もちゃんと動くようにしないといけ
    ない（保守）、必要であれば、機能を追加してアップデートしたり修正 しないといけない（運用）
    クラス（ソースコードレベルでのモジュール）< コンポーネント（デプロイの単位。.Netのdll, Javaの.jar）< アーキテクチャ
    ソフトウェアの人生：開発（設計・実装） →テスト→デプロイ→リリース→運用・保守
    ・開発した後もデプロイ、リリース、運用、保守がしやすければソフトウェアの人生全体をサポートできる
    ・では、デプロイ、リリース、運用、保守のしやすさはどうやって達成できる？
    →その鍵はコンポーネント（デプロイの単位）
    

    View Slide

46. #codepolaris
    SOLIDを超えて

    コンポーネントとは、デプロイの単位である。システムの一部としてデプロイできる。（第
    12章　コンポーネント）
    SOLID原則がレンガを組み合わせて壁や部屋を作る方法を伝えている原理だとするな
    らば、コンポーネントの原則は部屋を組み合わせて建物を作る原則である。大規模建築
    と同様に、大きなソフトウェアシステムは小さなコンポーネントを組み合わせて作られて
    いる。（第IV部　コンポーネントの原則）
    SOLIDは綺麗なクラス（プログラム）を作る、クラスを組み合わせるとコンポーネント（デプロイの単位）になる、コンポーネン
    トの組み合わせでソフトウェアシステムができる。
    →ソフトウェアアーキテクチャは最適な部品分け、組み合わせのアート
    

    View Slide

47. #codepolaris
    デプロイ、リリース、運用、保守の苦しみ

    ● デプロイ手順が複雑でデプロイのコストが高い
    ● リリースしたいのはこれだけなのに依存関係の複雑さのせいであれもこれもデプロ
    イ資源にいれないといけない(´;ω;｀)
    ● 修正したいのはここだけなのに依存関係の複雑さのせいでry)
    ● 修正しないといけない場所、、、どこ、、、、？（ソースコードが汚いor適切にクラス分
    けされてなくてbug fixに時間が掛かる）
    ● テストコード、、、、Code Coverage、、、、
    

    View Slide

48. #codepolaris
    デプロイ、運用、保守のためにアーキテクチャはどうあるべき？

    ● デプロイ
    デプロイのコストが高ければ、その分だけシステムの有用性は低下する。ソフトウェアアーキテクチャの目的は、システムを単一のア
    クションで簡単にできるようにすることである。
    ● 運用
    システムの運用ニーズを伝えるというものだ。アーキテクチャが優れていれば、システムの運用方法は開発者が見ればすぐにわか
    る（中略）つまり、アーキテクチャが運用方法を明らかにするのである。
    ● 保守
    保守の主なコストは、洞窟探検とリスクだ。システムを安定したインターフェイスを持つ独立したコンポーネントに分離しておけば、将
    来の機能の道筋が照らされ、意図せずに壊してしまうリスクを大幅に軽減できるだろう。
    第15章　アーキテクチャ
    

    View Slide

49. #codepolaris
    コンポーネントはどうあるべき？

    ● デプロイ手順が複雑でデプロイのコストが高い
    →Pipeline作ってCI/CD環境を整える
    ● リリースしたいのはこれだけなのに依存関係の複雑さのせいであれもこれもデプロ
    イ資源にいれないといけない(´;ω;｀)
    ● 修正したいのはここだけなのに依存関係の複雑さのせいでry)
    ● 修正しないといけない場所 is どこ、、、、？（ソースコードが汚いor適切にクラス分
    けされてなくてbug fixに時間が掛かる）
    →コンポーネント（デプロイの単位）の切り分けが適切ではないのかも？
    

    View Slide

50. #codepolaris
    再利用・リリース等価の原則(REP)

    ● 再利用の単位と、リリースの単位は等価になる。
    ● ひとつのコンポーネントを形成するクラスやモジュールは、まとめてリリース可能で
    なければならない。
    第13章　コンポーネントの凝集性
    

    View Slide

51. #codepolaris
    閉鎖性共通の原則（CCP）

    ● 同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更
    の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。
    ● SOLIDの単一責任の原則(SRP)をコンポーネント向けに言い換えたもの。SRPは
    「クラスを変更する理由が複数あるべきでない」という原則だったが、CCPは「コン
    ポーネントを変更する理由が複数あるべきではない」と説いている。
    第13章　コンポーネントの凝集性
    

    View Slide

52. #codepolaris
    全再利用の原則(CRP)

    ● コンポーネントがユーザーに対して、実際には使わないものへの依存を強要しては
    いけない。
    ● CRPはインターフェイス分離の原則(ISP)を一般化したもの。ISPは使っていないメ
    ソッドを持つクラスに依存しないように伝えている。
    ● CRPは、使っていないクラスを持つコンポーネントに依存しないように伝えている。
    ● 不要なものには依存しないこと。
    第13章　コンポーネントの凝集性
    

    View Slide

53. #codepolaris
    まとめ

    ● 開発した後もデプロイ、リリース、運用、保守がしやすければソフトウェアの人生全体をサポート
    できる
    ● DevOps的に幸福度高いアーキテクチャにするためにはコンポーネント（デプロイの単位）の分
    け方が鍵
    ● SOLIDは綺麗なクラス（プログラム）を作る、クラスを組み合わせるとコンポーネント（デプロイの
    単位）になる、コンポーネントの組み合わせでソフトウェアシステムができる。
    

    View Slide

54. #codepolaris
    Agileとアーキテクチャ

    

    View Slide

55. #codepolaris
    アジャイルって設計フェーズっ
    てないよね？
    設計ってどうすんの？
    アジャイルだと短いスパンで継続的
    にリリースしていかなきゃいけない。
    そんな短い期間でいいアーキテク
    チャってどう作ればいいの？
    1sprint(1 week- 1 month)で
    ちゃんとしたアーキテクチャつく
    るの無理ゲーでは？
    

    View Slide

56. #codepolaris
    クリーンではない（腐敗した）アーキテクチャ(1/2)

    硬さ
    変更しにくい。1つ変更するとあっちもこっちも変えないといけない。
    もろさ
    ここを変えるとあっちもこっちも（変更箇所と関係ない所）壊れる、、、、
    移植性のなさ
    ここって他でも流用できるんじゃない？って所があるのに、オリジナルの場所から切り離すことに大きなリスクがある。
    

    View Slide

57. #codepolaris
    クリーンではない（腐敗した）アーキテクチャ(2/2)

    

    扱いにくさ
    正しいやり方よりも誤ったやり方でやる方が簡単（ソフトウェア、開発環境両方とも）
    不必要な複雑さ
    これ意味ある？って感じの構造を内包している。（クラスの中に複数のクラス、メソッドの中に複数のよくわらかないメソッド）
    不必要なくり返し
    コードのコピペ、、、、
    不透明さ
    読みにくい。わかりにくい。（スパゲティコード）
    アジャイルソフトウェア開発の奥義　　第 2章　アジャイル設計
    

    View Slide

58. #codepolaris
    アジャイルにおけるクリーンなアーキテクチャの作り方

    ● どうしてアジャイルでは設計フェーズがないの？
    →どうせ変わるから。
    ● じゃあどうやってシステムの設計をクリーンに保つの？
    →DoD(完成の定義)、Acceptance Criteria（受け入れ条件）を明確に決めて、必要であ
    ればアップデートする。頻繁にUT（単体テスト）やAT（受け入れテスト）をやる。（最初に
    DoDやAcceptance Criteriaを満たすテストを設計して、それを満たすように開発する
    （TDD））
    

    View Slide

59. #codepolaris
    アジャイルにおけるクリーンなアーキテクチャの作り方

    

    ● 先を見越して複雑なことを考えない。DoDやAcceptance Criteriaを満たす最もシン
    プルな方法で実装。
    ● SOLIDやコンポーネントの原則（やるべき事を最小の単位で分離して、不必要な依
    存が発生しないようにする）に沿って考えると、先の難しいことは考えず、オブジェク
    ト単位でシンプルに実装できる。難しい設計とかは部品になるモジュールやコン
    ポーネントができてから考えればいい。
    

    View Slide

60. #codepolaris
    Agileの経験主義と創発的アーキテクチャ

    ● Waterfall：最初にしっかり分析して計画したから後はこれを計画通りにやればヨ
    シ！（理性主義）
    ● Agile: 人間そんな先のことまでわからないから、見通しが立てられそうな小さい単
    位に分割してやってみて、やってみて改善が必要だったら対応していこう（経験主
    義）
    ・Sprint単位での目標設定、計画、開発
    ・SOLIDに沿ったクラス単位での開発（まずはアーキテクチャを構成する最小の部品をちゃんと
    作る）→コンポーネントに結合 →アーキテクチャの創発 (Emergent Architecture)
    

    View Slide

61. #codepolaris
    まとめ

    ● 見通しができる小さい単位に分割して、DoDやAcceptance Criteriaを満たすように
    作っていく。
    ● 最初はアーキテクチャの構成の最小の単位（クラス・モジュール）をSOLIDの原則
    に沿うように作る（最小の部品をちゃんと作る）
    ● 作ったものは継続的にテストをして、常にリリース可能な状態にする
    ● 最小の部品（クラス）を作る→それを組み合わせてコンポーネントを作る　という流
    れをsprintを重ねて作っていく
    ● それを繰り返すとアーキテクチャが”現れる”（Emergent Architecture :創発的アー
    キテクチャ)
    

    View Slide

62. #codepolaris
    さいごに

    

    View Slide

63. #codepolaris
    アーキテクチャとアーキテクトは何の為に？

    ● アーキテクトの目的は、求められるシステムを構築・維持するために必要な人材を最小限に抑える こ
    とである。
    ● ソフトウェアアーキテクチャとは、 境界線を引く技芸 である。ソフトウェアの要素を分離し、お互いのこ
    とがわからないように制限する というものである。
    ● アーキテクチャの形状の目的は、そこに含まれるソフトウェアの開発・デプロイ・運用・保守を容易に
    することである。
    

    View Slide

64. #codepolaris
    メンバーによる輪読会やってみての感想

    ・クリーンアーキテクチャの概念が知れてよかった。
    　現役エンジニアとお話しして、働くイメージをつかめた。（by ねこさいん）
    ・他社のエンジニアと実際の業務でエンカウントしがちな設計の問題についてディスカッ
    ションできた（byしの）
    ・自分が見てきた運用しにくい&バグが出てきそうな設計をどう改善すればいいかイメー
    ジが持てた。コードがそこそこ書ける→保守・運用も想定したいい設計のイメージが持て
    て若干エンジニアとして視座が高まった気がする(by yurie)
    

    View Slide

65. #codepolaris
    References

    ● Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://amzn.asia/d/fPVihGj
    ● プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
    P13. よい実装をするための指標
    (KISS, YAGNI, DRYについて書かれてる） https://amzn.asia/d/7hydTCq
    ● DevOpsとアジャイルの比較
    P35. ソフトウェアの人生と
    DevOps https://azure.microsoft.com/ja-jp/overview/devops-vs-agile/
    ● アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
    P44- Agileとアーキテクチャ　https://amzn.asia/d/cudAF5n
    ● Emergent Architecture: Architecture in the Age of Agile
    P50. アジャイルの経験主義と創発的アーキテクチャ　
    https://medium.com/@steve.cornish/emergent-architecture-architecture-in-the-age-of-agile-9f21ba654845
    

    View Slide