忙しい人のためのClean Architecture

Slide 1

Slide 1 text

#codepolaris Clean Architectureって何？っていうのを開発者たちが考えてみた  yuriemori しのねこさいん

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

#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とアーキテクチャ

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

#codepolaris アーキテクチャというかそもそもアーキテクチャって何  クラス（ソースコードレベルでのモジュール）> < コンポーネント（デプロイの単位。.Netのdll, Javaの.jar） < アーキテクチャコンポーネントクラス

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

#codepolaris ありそうな誤解 

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

#codepolaris SOLIDの基本 

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

#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)

Slide 24

Slide 24 text

#codepolaris S:単一責任の原則  (SRP:Single Responsibility Principle)  There should never be more than one reason for a class to change. （→変更するための理由が、一つのクラスに対して一つ以上あってはならない）一つのクラスは一つの機能のみを担当する

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

#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」の原則にのっとり、置換可能である

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

#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. （→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである）外側のクラスが内側のクラスに依存するようなことはしてはいけない (インターフェースを経由すると、依存関係を断ち切ることが出来るのでこの本で推奨されているが、アノテーションを使うことでも回避できる)

Slide 29

Slide 29 text

#codepolaris クリーンアーキテクチャ的に考える  幸福度の高い実装 

Slide 30

Slide 30 text

#codepolaris Javaのコードを介して実際に見てみよう  Javaのannotationやデザインパターンを使ってクリーンアーキテクチャの思想に則ったコードを実装してみる   使用するフレームワーク ● Spring Framework ● Lombok ● JPA/Hibernate

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

#codepolaris Agile/DevOpsから考える  クリーンアーキテクチャ 

Slide 43

Slide 43 text

#codepolaris DevOpsから考えるClean Architecture 

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

#codepolaris Agileとアーキテクチャ 

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

#codepolaris クリーンではない（腐敗した）アーキテクチャ(1/2)  硬さ変更しにくい。1つ変更するとあっちもこっちも変えないといけない。もろさここを変えるとあっちもこっちも（変更箇所と関係ない所）壊れる、、、、移植性のなさここって他でも流用できるんじゃない？って所があるのに、オリジナルの場所から切り離すことに大きなリスクがある。

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

#codepolaris さいごに 

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

#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