iOS Clean Architecture勉強会のまとめ

この文章は2020年1月21日に行われた「[iOS Clean Architecture勉強会 sponsored by Sansan](https://connpass.com/event/158269/)」という勉強会のまとめです。

# 発表内容

## yimajo: 「クリーンアーキテクチャとiOSアプリ開発のためのVIPERと」

- 依存関係逆転の原則(DIP)について
- VIPER
    - VIPERの種類色々ある
    - VIPERはDIPを使ってない
- DIPを使ってない場合の依存を取り除くには
    - Interactorごと取り替える
    - DBに依存したデータを表示するためのstructなどに置き換える

### スライド

https://speakerdeck.com/yimajo/kurinakitekutiyatoiosahurikai-fa-falsetamefalseviperto

## dotrikun: 「ゼロイチフェーズからのClean Architecture」

- DeNAテックカンファレンスあります
- 新規アプリでクリーンアーキテクチャは食い合わせ悪いのか
    - これまで3本は非CA
    - 4本目はCAを採用
- AppRootViewController使ってる
    - 起動時
- RouterにHUDいれてる
    - 悩んでる
- Embedded Framework
    - UIではないEntity, UseCaseをEmbedded Frameworkで分けている
    - どこになにがあるかは慣れた
    - あとでWatchようにしたりするよりさきに分けておくと楽だった
- ドメインロジックで切り出す
    - 他のアプリでも使える
- クリーンアーキテクチャで先に作る「技術的投資」
    - 大きな会社のプロダクトなのでリターンが見込めそう
         - スタートアップだと厳しそう

### スライド

https://speakerdeck.com/dotrikun/ios-ca

## ChaaaaaaaaaaanU: 「VIPRE + MicroViewController を組み合わせて大きな機能を実装した話」

- Sansan株式会社でSansanアプリを作ってる
- 人物詳細
    - かなりリッチな画面（機能が多い）
    - 1つのVIPERモジュールではきつい
        - なのでMicroViewController使う
        - 各ViewControllerの中にVIPERの構成
            - Routerがなかったりする
        - MicroViewControllerの[Instantiatableプロトコル](https://github.com/mercari/Mew/blob/0.2.2/Sources/Mew/Protocols/Instantiatable.swift#L22-L27)はVIPERのRouterと役割がかぶる
            - 中途半端に両方を使わない

### スライド

https://speakerdeck.com/yuichirokato/ju-da-naji-neng-wo-viper-plus-microviewcontroller-deiigan-zinishi-zhuang-sitahua

## LT5分 kageroupro44: 「クリーンアーキテクチャ導入が、 どのような作業に影響を及ぼすのか考察」

- インターンでfancというアプリ作ってる大学三年生
- クリーンアーキテクチャ導入後
    - レイヤーやクラスが責務によって分かれた
        - 担当ワケできたので作業の短縮できた
    - 開発者感共通認識
        - 共通認識があるので全体的にスピードが上がった
    - 実装に統一感が生まれた
    - ファイルが増えた

### スライド

https://speakerdeck.com/yutonakano/kurinakitekutiyadao-ru-ga-dofalseyounazuo-ye-niying-xiang-woji-bosufalsekakao-cha

## hirothings:「VIPER with アーキテクチャ選定 実践入門」

- VIPER以前の課題
    - ViewControllerで個別に遷移してた
    - プレゼンテーションロジックとデータ用のロジックが混在
- 選定（VIPERに至る）
    - データバインディングは必要なし（インタラクティブいらない）
    - DBもなし
    - サンプルを作ったりして選定した
- VIPERにしてよかったこと
    - ユニバーサルリンクからでもRouter使って画面表示が楽
    - iOSアプリ設計パターン（Routerの記述がいい）
    - テストしやすい実装を後押ししてくれる
    - [単体テストのはじめ](https://speakerdeck.com/yokoyas000/dan-ti-tesutofalsehazime)というスライドが良い
- VIPER良い点
    - 層が分かれているので担当が分かれている
    - Embedded Framework
        - UIに関連する/しないでフレームワーク分割
            - 正しさよりも影響範囲で分けた
- CM
    - 個人で作ってます
        - 作りはMVC
            - アプリの成長によってアーキテクチャを選定するのでクリーンアーキテクチャじゃない

### スライド

https://speakerdeck.com/hirothings/viper-architecture

## takasek: 「モバイルアプリにおける『中心』とは何か」

- 中心とは？
    - 創界山！！
- クライアントアプリはハブ
- JSONの色付けは難しい
- クライアントアプリの「ドメインロジック」は「エンティティ=中心」にあるとは限らない
- CA本19章
    - 方針はさらに小さな方針に分離される

### スライド

https://speakerdeck.com/takasek/20200121-the-center-of-the-client-number-ios-ca

# 座談会での質問

参加者の皆さんに頂いたアンケートから、発表者に質問に答えてもらいました

## 質問: Routerの呼び出しはenumだけだと他のパラメータどうしてるんだろ

- ChaaaaaaaaaaanU
    - 情報はenumに入れている
        - コールバックもある
    - ボイラープレートはenumに吸収させたい

## 質問: 個人アプリでCA導入しようと思うきっかけがあれば教えてほしいです。

- hirothings
  - アプリの複雑性よりも上位の問題が気になるのでCAでやってない
  - サーバサイドを気にしている
    - サーバサイドはテスト書いている
  - Firebaseだから？
    - そう
      - お金がかかわるから
      - NoSQLでセキュリティ・ルールが必要

## 質問: CA初学者にCAの概念と、実際の実務での差分のうまいフィッティングがあれば教えてほしいです。

 - 役割を考えるとシンプル
  - アプリに関係ない部分が外側にある
    - 外の世界をつなげるとこ
      - それで4つの世界
          - アプリに関係ある/ない/糊/外側