# クリーンアーキテクチャ読書会 in 鳥取

- 参加者
- キックオフ
- kmt-t（発表者）
- こーへい氏（発表者）
- ちんも氏
- すずむら氏
- tomitakeFoo氏
- ふとなか氏
- OZBOSE氏（残念不参加）
- 第二回
- kmt-t
- こーへい氏
- すずむら氏
- tomitakeFoo氏

# アジェンダ（キックオフ）
- 概要
- https://www.amazon.co.jp/dp/B07FSBHS2V/
- クリーンアーキテクチャのオンライン読書会です
- キックオフなので最初の方と全体の話になると思います
- 読書メモ、感想文を書いたことのある人は開示お願いします
- 時間がないので読むところは絞ります
- 基本的な進め方
- ファシリテーターが章ごとに要約を説明する
- 参加者のレベルに合わせて前提部分はすっとばす
- わからないところの質疑応答
- わからないところを本で確認する
- 時間割
- 15:03〜 自己紹介
- 15:20～ 参加者のレベル感の確認
- 15:30～ 進め方の話
- 15:40～ 予習すべき内容の提示
- ～3部まで
- 俺の考えるクリーンアーキテクチャ
- 発表者募集中！
- 15:50～ @kmt_t
- 16:10～ @kou029w氏
- 16:30～ 質疑応答・フリーディスカッション

# アジェンダ（2回目）
- 時間割
- 14:03〜 自己紹介（新規参加者のみ）
- 14:05～ 参加者のレベル感の確認（新規参加者のみ）
- 14:10～ 進め方の話
- 14:20～ まとめ（22章）
- 14:40～ 依存関係逆転の法則（11章）
- 15:00～ コンポーネント（12～14章）
- 15:20～ 現実へようこそ（21章）
- 15:45～ 質疑応答・フリーディスカッション

# 質問リスト
- Q. IDDD本とは
- A. https://www.amazon.co.jp/dp/B00UX9VJGW 実践ドメイン駆動設計
- SOLID原則
- > これらの原則は、アメリカのソフトウェアエンジニアでインストラクタでもあるRobert C. Martin（英語版）により提唱された多数のソフトウェア設計の原則の一部を集めたものとなっている[1][2][3]。SOLIDはどんなオブジェクト指向の設計にも適用できるが、アジャイル開発や適応的ソフトウェア開発（英語版）などの方法論の中心的な考えにもなっている。SOLIDの原則の理論は2000年に公開されたMartinの論文Design Principles and Design Patternsで発表された[4]ものであるが、SOLIDという頭字語自体は後にMichael Feathers（英語版）によって導入されたものである[5]。 https://ja.wikipedia.org/wiki/SOLID より
- 依存性逆転ってどういう実装になるだろう?
- ファクトリクラス?
- ポイントは下位レイヤーを参照しない、依存しないという点
- 上位レイヤをビルドするとき切り離されているので下位レイヤのビルドが不要
- 図について、どれが上位?
- 円の内側 = 上位
- レイヤーの境界にとにかくインターフェースを切り出せばOK?
- 設計原則としての話であって、最重要ポイントはコストの最小化。全部インターフェースとして切り出せばよいというのはおそらく間違い
- クリーンアーキテクチャなるものがあって、このルールに従え、という話ではない。あなたのアーキテクチャの問題を見つける、解決する手立てを提供

# 次回以降の読書会で読みたいところリスト
- 依存関係逆転の法則（11章）
- コンポーネント（12～14章）
- 現実のWebの話
- 綺麗ではない現実世界では
- みんなクリーンにしようとして苦労している
- 良い事例ネタないか探す

# 予習および復習に最適な動画
- 世界一わかりやすいClean Architecture #csharptokyo
- https://www.youtube.com/watch?v=pbCRHAM5NG0
- 情報まとめてから動画見たらほぼ言ってることが一緒だった

# Zoomチャットのメモ
fukuta
> Uncle Bob もGUIのアプリ作るの得意じゃないと思ったりする

suzumura
> GUIの部分は「UI」だけに押し込んでますしね
> 扱うアプリの規模の前提があるように思います

fukuta
> 階層型アーキテクチャの時点で、レイヤーをすっ飛ばすのは基本を外しているので特に新しい話でもない
> シンプルな話をbobおじさんがした結果、WebエンジニアたちがヒーってなっててCleanなWebアプリってなんやねん、こうじゃないかああじゃないかってやるけどbobおじさんは多分そんなことはしたことがないはず
> bobおじさんは人の作ったフレームワーク嫌い

fukuta
> アーキテクチャとアーキテクチャスタイル
特定のシステムの構造＝アーキテクチャ RESTみたいなもの＝アーキテクチャスタイル

fukuta
> 依存性逆転、Inversion of Control, Dependency Injection の話は、ちんも的には 2000年ごろhotだったと記憶している。その後、Javaとかフレームワークという道具にDIの機能とかが入ってきた。

fukuta
> 夏にモノリスからマイクロサービスへという本の翻訳のレビューをしていて良書だと思うんだけど、最初っからマイクロサービスとかコンポーネントとか考えても無駄で、railsとかでさらっとモノリシックに価値を提供しつつ、他サービスで利用できる価値が発見されたらサービスの分割に移っていく話だった
分ける目的がないと、分けたコストがそのまま残る
そう言えばボブの本に出てくる、RDB絶対使わないぞって戦ってその会社やめた話、いろいろ思うところがあった。

fukuta
> Clean* は、単にボブの本・講演のタイトルの頭につくやつだから、そういうアーキテクチャがあると思うと迷う気がする。依存性逆転の原則イイよ！若造もちゃんと理解しとけよ！くらいに受け取るべきw
この次の本は、Clean Agile でした。
その前の本は、Clean Coder, さらにその前は Clean Code
アーキテクチャってデザインの領域、つまり人のArtga
Artな要素が出てくる領域だから、「このルールを使えばできる！」というより、小さな原則や大きな本人のこだわりを、現実に対して駆使するようなことだと思う

fukuta
> 本人動画でも言ってたけど、「Clean hogehoge」とか偉そうだけど、俺も十分年取ったから偉そうにしてもいいだろと思ってつけたhahaha って言ってた
アーキテクトがふにゃふにゃしてちゃダメだと思うから、ボブおじさんは素晴らしいアーキテクトだと思う
何か原則を見つけたら、それを全ての事例に当てはめて、美しい構造を作れるのではないか、という夢を多くの人に見せて、Web界隈がこうすれば、こうすれば、という記事をたくさん産んだと思った
そして多くのエンジニアが、依存性逆転の原則を駆使するようになって、レベル＋１した、という業界への貢献があったと思う
でも依存性逆転の原則は21世紀の最初で語られてて、そこからJavaEEとかSOAPとかActivbeTemplateLibraryとかスンゲーインターフェイスの世界に突撃した歴史がある

fukuta
> エンティティが見つけられないとドメインモデル貧血症に陥るんだけど、ボブはどうやってビジネスドメインを作るかは一切話してなくて、章としてもビビるほど薄い。
まあ端的にこの本は依存性注入をフラクタルに適用できるぞ。それがアーキテクチャで変わらないルールだ、ってことを言いたいはず
入江くんはまだ基本OFFにしてるのかなJS

fukuta
> Webはハイパーメディアから、あるところでプラットフォームになったんですよね by 山本陽平

# 第二回の話題
## まとめ（22章）
- BCEとこの本のエンティティは違う
- アーキテクチャの原則
- 既存のアーキテクチャが全て満たしている原則がある
- クリーンアーキテクチャも同様
- 4つのレイヤ
- エンティとユースケースの分割
- エンティティの方が抽象、不変
- エンティティは業務ルールの仕様
- ユースケースはアプリケーションの振る舞いの仕様
- 小規模ではそこまで明確にわけなくていいかも
- 外の二層
- みんなMVCなどで馴染み深い
- そんなに軽い話ではない
- あくまでレイヤ分割の例なのでそこまでこだわらない
- レイヤ分けは4つでなくてもいいよ
- 境界
- 依存関係を分離するところでレイヤの境界ができる
- 境界はレイヤ以外にもある
- 同じレイヤでも関心事で境界はある
- 境界をこえるデータ
- DTOを使う
- 欲しいデータは内側のレイヤで定義する
- 動的型付言語だとデータ型を定義する必要がなくて楽
- 静的型付言語VS動的型付言語
- 動的型付言語のいいところ
- 典型的なシナリオ
- MVCフレームワークでは馴染み深いので割愛
- まとめ
- 単純なルール＝依存性の話
- 結局これだけ
## 依存関係逆転の法則（11章）
- 依存性逆転の法則はわかるが実装がわからない
- AbstractFactoryを何故用いるのか
- どう実装するのか
- 普通にやると面倒
- kmt-tが試した範囲ではDependencyInjection使った
- 実装のハマりどころが多いけどよくわかってない
- 次回勉強会するなら実装の話をする
## コンポーネント（12～14章）
- リリースが分かれる
- リリースが分かれるならコンポーネントもわかれる
- チームが別
- チームが分かれているのはやりやすいから
- 同じリポジトリで作業するなら同じチーム、組織は別でも問題ない
- テンション図
- ここに集約される、非常に良い図
## 現実へようこそ（21章）
- Webって小さい？
- 小さくないがそれでも言い切る
- 立場、経験、スコープ、大局観
- 経験の差で言うことが変わってくる
- ボブおじさんはかなり長いスパンの話をしている
- フレームワークに依存するメリット
- フレームワークは重要だがそれでも言い切る
- 価値の提供が優先される場合がある
- 価値の提供はテーマ
- テスト大事
- kmt-tはWebの技術を取り入れたい（テスト、デプロイ、CI/CD、運用）
- ちょっとでもいいのでテストは書いていみよう
- 予算を確保しよう
- お金の話をしよう
- お金で納得する人はわかりやすい

# 俺の考えるクリーンアーキテクチャ
## こーへい氏
### 自己紹介
渡邉浩平 @kou029w
- 2001- 家にインターネットがつながる
- 2005- ひきこもり不登校、ほぼ毎日Web
- 2016- ソフトウェアエンジニアとしてWebアプリケーションの開発などに携わる

### 本題「クリーンアーキテクチャ」
クリーンアーキテクチャ自体は、ビジネス固有の構造（エンティティ）と方針（ユースケース）があり、そこから同心円状に構成される被依存関係、非循環依存グラフのこと
詳しいことは本書またはkmt-tさんの説明をご覧ください

以下は本書を読んで自分の思ったこと

### 疑問
1. そもそもどうやってエンティティを発見するんだろう
2. React Componentの位置づけ

### そもそもどうやってエンティティを発見するんだろう
いろいろな観点で全体最適を目指して評価し続けることが大切
変更の軸の話、テスト容易性とか単一責任の原則とかコンウェイの法則とか
ヒントは本書にたくさんあるのでご覧ください

### React Componentの位置づけ
Web、特にフロントエンドの視点から
#### 背景
現代のWebはもはやJSが中心
たとえばブラウザーの設定からJSを無効化すると、ほとんど機能しない
Amazonはボタンを押してもカートに入らず、YouTubeは何も表示されず、Google検索(の一部)くらいしか機能しない
テンプレートエンジンはJSX/TSX、デザインシステムはPostCSS/CSS-in-JSなど、JS前提という流れが存在
従来のWebページのようなHTML(構造)/CSS(見た目)/JS(制御)での分割とは異なり、コンポーネント(機能)での分割の存在

#### 疑問と答え
個人的に疑問だったのは、標準的なHTML/CSS/JSで済むならそれが単純で良いし、あるいはSVG/JSで済むならそれが単純で良いが、それだけで上手くいかなかったのはなんでなんだろう、という点
その答えの1つとしては、Webデザインもアーキテクチャの中の詳細に過ぎなくて、コンポーネント、つまり開放/閉鎖原則の観点でデプロイ可能なレベルに上手に整理できていれば、詳細はどうでも良いよな、ということなんだろうなと、本書を読んでて思いました

## kmt-t
### 自己紹介
松永卓也 @kmt_t
- 画像処理、信号処理、機械学習、OSミドルウェア、検査機が専門分野
- WebはわからないのでASP .NET MVCしか使えない。PHPはトラウマ
- 最近デスクトップアプリ開発のためPrism覚えた
- 経歴
- 就職氷河期到来
- 1999 たんなるニートだったが就職氷河期だったので就職浪人と言って逃げ切る
- 2000-2005 VB/C++/C#/鳥取の工場で前半は製品開発関連、後半は検査機開発
- 2006-2009 C言語/転職、難しい開発をした気がするが暗黒期で記憶喪失
- リーマンショック到来
- 2010 たんなるニートだったが仕事のないフリーランスと言って逃げ切る
- 2010-2012 C言語/大阪に転職、製品開発
- 2012-2017 C++/PHP/Ruby/Python（機械学習）/鳥取に戻って業務システム開発
- 2018- C/C++/C#/転職、鳥取の工場で製品開発、最近検査機開発始めた
- 2005年の前まではマーチンファウラーのファンだった。当時DDDはスルー。不覚
- 今検査機をクリーンアーキテクチャで開発中。クラス図は読書会で公開できるかも

### 全体
本には書いてない自分の感想（そのように解釈したのも含む）は章節項の頭に「（感想）」と書く

#### （感想）読書のモチベーション
- 昔からデスクトップアプリの開発が苦手
- 今はC#でもPrismとかあって非常に良い
- それでもしんどいのでこれさえ守っておけばオッケー的な定石を知りたい

#### （感想）自分の今の結論
- 超要約
- レイヤアプローチ
- 外側は直近の内側にのみ依存する
- 依存関係が逆にならないように「依存関係逆転の法則」を用いる
- 内側、外側に入る固有名詞は重要ではない（システムで違う）
- 何が内側で何が外側かを見極めるのは実は難しい
- クリーンアーキテクチャとはメタアーキテクチャである
- メタアーキテクチャはすべてのソフトウェアで同じである
- クリーンアーキテクチャとは依存関係の話である

#### （感想）なぜ自分がメタアーキテクチャと呼んでいるのか
- ユースケースが内側にくるのが一般的だが、何が内側で何が外側でも問題ない
- 一般的なアーキテクチャは構造について言及している
- クリーンアーキテクチャは構造のルールについて言及している
- 良いアーキテクチャの構造を示すための定理が「原則（ルール）」

#### （感想）書籍は以下について書かれている
- モジュール
- オブジェクト指向の原則
- コンポーネント
- コンポーネントの原則
- アーキテクチャ
- 境界
- バウンダリとも呼ぶ。どこでレイヤを分けるか？
- クリーンアーキテクチャ（自分の言うメタアーキテクチャ）
- クリーンアーキテクチャにおける設計の勘所と俗説の嘘（書籍の1/3）
- ソフトウェアの歴史（書籍の1/4）
- 読むのが大変なのはコンポーネントのところまで（がんばろう）

### 内容
#### 前ふり
- ソフトウェアアーキテクチャの真理
- 「アーキテクチャの【ルール】はすべて同じである！」

#### モジュール
- （感想）よく知られているので「依存関係逆転の法則」だけおさらい
- オブジェクト指向の原則
- 単一責任の原則
- 開放閉鎖原則（Open-Closed Principle）
- リスコフの置換法則
- インターフェイス分離の法則
- 依存関係逆転の法則
- 依存関係逆転の法則
- 
- レイヤの境界をまたがる矢印の向きが逆なのに注目

#### コンポーネント
- （感想）コンポーネントの善し悪しの議論はされないことが案外多い
- コンポーネントの原則
- よく知られていないので次回以降で解説
- 再利用リリース等価の原則（REP）
- 閉鎖性共通の原則（CCP）
- 全利用の原則（CRP）
- 三すくみでトレードオフになっている
- 
- コンポーネント図の使い方
- （感想）クリーンアーキテクチャでは重要な図
- コンポーネント間の依存に問題がないか
- 循環依存の検出
- 循環依存があるとビルドできねえよ
- （感想）某社で.NETのシステムで問題になっているのを聞いた
- 安定依存の法則
- 依存するなら安定した方に依存
- 外側から内側に依存するのがクリーンアーキテクチャなら内側が安定してないとダメ
- 安定度・抽象度等価の原則
- 抽象度が高いほど安定度が上がる
- 安定度の高い内側を改変する場合は「開放閉鎖原則」を使う
- 安定度と抽象度のマトリクス
- 
- 物事には程度がある
- 抽象度が低く安定度が低すぎるとしんどい
- 安定度が高く抽象度が高すぎると無駄

#### アーキテクチャ
- 方針と詳細
- 方針＝アーキテクチャ、アーキテクチャは安定度の高い抽象レイヤに存在する
- 詳細＝実装、実装は安定度の低い具象レイヤに存在する
- フレームワークのような詳細の決定は遅延させる
- 独立性
- アーキテクチャがユースケースの意図を表現する
- ショッピングカートのアーキテクチャはショッピングカートに見える
- アーキテクチャはシステムの振る舞いに影響しない

#### 境界
- （感想）何が内側で何が外側かという判断の難しい話につながる
- いつ何に境界線を引くか？
- UIはビジネスルールにとって重要ではない（外側の存在）
- データベースも外側
- ビジネスルールは内側なので切り離す
- フレームワーク、ライブラリは外側なので後で決める
- 境界線は変更の軸のあるところに置く
- データの受け渡し
- インターフェイス、データの定義は呼び出される側（つまり内側）にある

### （まとめ）クリーンアーキテクチャの全体像
#### 全体像
- レイヤアプローチ
- 外側は直近の内側にのみ依存する
- 依存関係が逆にならないように「依存関係逆転の法則」を用いる
- 安定度と抽象化の話
- 抽象度が高いほど安定度が上がる
- 内側ほど抽象度が高いことになる
- 境界の話
- 標準的なレイヤの「あくまで例」
- UIとかWeb、RDBMS、デバイスはIOなので外側
- IOを抽象化、制御するレイヤがその内側
- ビジネスルールを制御するのがユースケースでその内側
- ビジネスルールをエンティティと呼び、最も内側

#### （感想）ちなみに
- 組み込み開発でも適用可能なアーキテクチャ
- MVVMがクリーンアーキテクチャである例示
- 
- クリーンアーキテクチャの例の図を参照
- ビューが一番外の青い部分
- ビューモデルとモデルが緑の部分（密結合が許される）
- サービスが赤い部分
- サービスから呼ぶビジネスロジックが黄色の部分
- モデルのうちRDBMSアクセスはORM（またはDAO）を介して青い部分に戻る
- 依存関係と抽象度、安定度を確認すること
- MVVMはクリーンアーキテクチャに含むことができる
- つまりMVVMとクリーンアーキテクチャはアーキテクチャのメタ度のレベルが違う
- BCE、3階層アーキテクチャとの違い
- BCE
- 
- メロンを左に倒した図形が「バウンダリ（B）」
- 再読み込みボタンみたいな図形が「コントロール（C）」
- 丸の下に棒がある図形が「エンティティ（E）」
- 3階層アーキテクチャ
- 
- 非常に見慣れているので詳細割愛
- これらはレイヤアプローチだが、依存の方向の考え方が違う
- これらだとUI（BCEで言うバウンダリor3階層のプレゼンテーション層）が最上位になる
- 依存の観点がないと古い人にはクリーンアーキテクチャは直感に反す
- 書籍の中ではBCEはクリーンアーキテクチャに含まれると言及
- 書籍の中では3階層はアーキテクチャでなくトポロジだと言及