More than 5 years have passed since last update.

iOSにおけるクリーンアーキテクチャよもやま話 #swtws

Last updated at 2017-01-14Posted at 2017-01-14

この記事は何？

Swift TweetsでTweet LTさせていただいたもののまとめになります。イベントのスポンサーとして Qiita に許可をいただいた上で、このような形（ツイートの引用）で投稿しています。

発表形式

Twitterのアンケート機能を使って話す内容を決めてみました。短い5分のLT時間で、できるだけニーズある話をしたかったという意図での試みでした。

【アンケートのお願い】
いきなりですがクリーンアーキテクチャに関してLTします田中です。
参加者の皆さんが気になることのアンケートを取りたいです。
アンケートの結果に応じて話す内容を変えようと思ってます。

iOSにおけるCAに関して気になるところはどこですか？#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

クリーンアーキテクチャに対する意識調査にもなってよいアンケートだったなと個人的に思っています。

もともと3つ話を作っておいてありました。本番では得票数の多かった**話その1の「そもそもCAってなに？」**の内容をTweetしましたが、せっかく用意したのでその他も公開しちゃいます。

iOSにおけるクリーンアーキテクチャよもやま話

※ここで使っているCAという表記はClean Architectureの略になっています。

はじめに

🍺など飲みながらゆるく始めさせていただきます。

それでは聞いてください、
「iOSにおけるクリーンアーキテクチャよもやま話」#swtws pic.twitter.com/zdpSXKH3OW
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【自己紹介】

おばんです、クラスメソッドでiOSをやりながらブログを書いている田中賢治といいます。
アイコンの通り、一部では「ダンボールの人」と呼ばれています。

詳しくは👇https://t.co/1WAWbzjLuy #swtws pic.twitter.com/fMDSK4Aozy
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【今日する話の説明】

今回はアンケートを取った中の「そもそもCAってなに？」について話していきますが、みなさんの発表が終わり次第他の話も垂れ流します。Qiitaにもまとめますのでご安心を。（というか話したい）

100票以上集まりました、すごい。#swtws pic.twitter.com/PsAHNv2mc0
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

話その1: 「そもそもCAってなに？」

【元ネタ】

元ネタと翻訳版は以下のリンク。https://t.co/vblzZQgx06 https://t.co/DA6OM0Z57x

CA（=クリーンアーキテクチャ）に関してはいくつかの要件が元ネタに書いてあるけれど今回は省略。是非読んでみてください。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【iOSにおけるCA】

僕がiOSでCAを採用するにあたって大いに参考にさせていただいているのが以下のリンク先です。むしろパクってます、ありがとうございます。
サンプルコードも載っているのでとてもわかりやすいです。https://t.co/RQv7olSnqP #swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

この記事ね。#swtws pic.twitter.com/BLn2b14idB
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【iOSにおけるCA】

iOSにおけるCAはおおまかな説明をすると添付している画像の通りの層と役割ごとに分けた設計です。(前ツイートのリンク先よりお借りしてます)
役割ごとの説明は先述のリンク先で説明されています。#swtws pic.twitter.com/o11PAgZnA2
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【iOSでCAを取り入れると良いこと】

以下が挙げられます。

・役割を分けることでMV○系におけるModel部分の曖昧さが無くなるので、エンジニア同士の経験値の差を埋めてくれる
・処理とデータの流れが追いやすい
・疎結合な作りなのでテストしやすくなる#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【iOSでCAを取り入れるとつらいこと】

・導入コストが高い
・ファイル数・コード量が増える

複雑なアプリor開発期間の長いアプリでないとオーバーコストな設計なので採用には見極めが必要。後者に関しては僕の後の @yhirose741 さんから詳しく説明があるかも#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CA導入までの流れ】

・CAは理解するのが難しい。一度簡単なアプリを「チームで」作ってみるとよい。
・いきなり案件導入するとチーム内で認識の齟齬が生まれてしまって苦労する。（体験談）

続きはWebで。https://t.co/nqkoBtyNM6 #swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

この記事ね。#swtws pic.twitter.com/4ZZSSkb2vD
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【さいごに】

以上、「そもそもCAってなに？」についてお話ししました。

今日の発表がみなさまのより良い開発の一助となれば幸いです。ごTweet聴ありがとうございました。(続く#swtws pic.twitter.com/1iVuqKaatX
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

発表後

この後のフリートークでは

・アンケートの中の取り上げなかったトピックの話（発表用に話は用意してある）
・CAと他のアーキテクチャの比較の話
・CAに則ったコードって実際どんな風に書くの？

などなんでもウェルカムです。気軽にお声がけください。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【宣伝・参考・関連】

あと勉強会やってます、よろしく！！！📦https://t.co/tff3kvnJUg https://t.co/RQv7olSnqP https://t.co/Ty9aw4hEvU https://t.co/nqkoBtyNM6 #swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

以上、温かみのある手Tweetでした！ありがとうございましたー#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

話その2: 「CAを採用するとなにが良いの？」

勝手にSwift Tweets 第二部

「CAを採用するとなにが良いの？」

#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CAを採用した際のメリット】

以下が挙げられます。

1. MV○系アーキテクチャにおけるModelという曖昧な存在を細分化して明確にしてくれる
2. 処理とデータの流れが追いやすい
3. テストしやすい#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【1. MV○系におけr(ry】

設計の力はエンジニアによって差が出がちです。
それに対してCAは層と役割を細分化することによって明確な設計指標を提示することができます。
力量や好み関係なく統一した設計で開発を進めることができるのは大きなメリットです。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【2. 処理とデータの流れが追いやすい】

CAは依存を単一方向に統一した作りになっているので、処理の流れが追いやすいです。
VC -> Presenter -> UseCase -> ... と処理は流れて、戻ってくるときは必ずその逆の順になる作りなので、#swtws pic.twitter.com/pPlD4cOAFE
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【3. テストしやすい】

役割 = 機能として細かく分割されて独立しているのでテストしやすい作りになっています。
この話に関しては前の発表の参考リンクのサンプルコードにも載っていますが、各役割はそれぞれインターフェースを作る実装となることもうまく作用します。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CAを採用した際のデメリット】

これについてはさきほどの「そもそもCAってなに？」で言った通り。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

話その3: 「CAを採用すべき場面ってどういうとき？」

そして最後。
アンケートで「そもそもCAってなに？」という話と票が割れた
「CAを採用すべき場面ってどういうとき？」#swtws pic.twitter.com/598ILq8T6x
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CAを利用すべきシーン】

以下が挙げられます。

・アプリの作りが複雑な場合
・アプリの開発期間が（大体）1年以上の規模の場合（メンテなど含む）

そのアプリの複雑さと開発規模で考えます。アーキテクチャ選定の具体的な線引きについては、今度ブログに書きます。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CAを利用すべきでないシーン】
利用すべきシーンに当てはまらない場合です。
なぜかといえば、CAは非常に大きな作りをした設計だからです。ファイル数・コード量がとても増えるため、CA以外の設計と比較した時に圧倒的にアプリを作るためにかかる工数が増えてしまうからです。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CAを利用すべきでないシーン】

どれくらいファイルが増えるかといえば添付の画像の役割分、インターフェースと実装をそれぞれ作る必要があります。作ったファイルにはそれぞれの実装が書かれますので、工数が増えるということがお分かり頂けると思います。#swtws pic.twitter.com/vPOWc8Wl6i
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【CAを利用すべきでないシーン】

添付画像はCAでログイン機能を作ってみた時のものです。
お気づきになられただろうか...、画面左端のファイルインスペクタに映る圧倒的ファイル数...。もう一度ご覧いただk（ry

ちょっと一機能作るだけでもこんだけ多くなる#swtws pic.twitter.com/ZfIZOj0AnF
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【補足】

あと一人開発の時にCAは要らない。個人開発で、CA実装の練習と思って作っているアプリがあるんですが、実装の重さと一人開発の寂しさで死ぬ。#swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

【その他のアーキテクチャとの比較】

これまで述べてきたようにCAの採用にはそれがコストに見合うかの見極めが肝心です。

他にもMVCやMVP、MVVMにVIPERなどありますが、僕の感覚は添付の画像の通りです。詳しくは省きますが気になる方は後ほどリプください。#swtws pic.twitter.com/AYO8S2Y01i
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

以上でっしたー。TweetできたのでQiitaにまとめまっす😗 #swtws
— ロスリックのダンボー田中 (@ktanaka117) 2017年1月14日

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up