賢治(147)54この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。はじめにおばんです、給料日を過ぎたらいつでも給料日前、田中です。18日目の記事になります。「もうやだクリーンアーキテクチャの実装重すぎだよおおおぉぉぉぉ」と思っている方この記事はなに?クリーンアーキテクチャは昨今の複雑なアプリケーション開発において非常に有効な設計ではありますが、同時に開発コストを要する点や包含する要素が多いために理解が難しい点などがデメリットとして挙げられます。この記事では私がクリーンアーキテクチャでアプリを実装した経験をもとにして、クリーンアーキテクチャのメリット/デメリットをプロジェクトの規模や複雑さに応じて要素を活かし、状況に合わせて使える形にできないかと試した以下の3つのパターンを紹介していきます。私がクリーンアーキテクチャでアプリを実装する際には@koutalouさんが公開している以下の二つの資料をもとに実装をしていますので、これら二つも合わせてお読みください。パターン紹介クリーンアーキテクチャでの実装まずデフォルトの形のクリーンアーキテクチャでの実装を紹介します。}}BuilderというApplication層の中の役割によってDIを行いつつ、各役割の間にはインターフェースを作成してそのやり取りを行うという作り。ここではBuilderの他にPresenterを例として載せています。protocolに準拠させたListViewControllerを弱参照で保持することにより、ビジネスロジック(UseCase)から返ってきた結果に応じて、ViewControllerに描画ロジックを書くことなく描画を行うことができるという作りになっています。これによりViewControllerの肥大化を防ぐこととなります。このようなクリーンアーキテクチャには以下のようなメリットとデメリットがあります。メリットViewControllerの肥大化を防げる層と役割が明確に分かれているので、チームメンバーの経験に依ることなく設計を統一できる各役割の独立性が高いため、テスタビリティが高い特にチームメンバーの経験に依る設計思想のばらつきを少なくすることができる点は非常に優れています。MV○系のアーキテクチャの"M"にあたるModelという線引きはあまりにも漠然としていると私は思っています。経験値の高いメンバーが考えるModelと新卒ぺーぺーのまさに自分のようなエンジニアが考えるModelとで、先を見通した抽象化やグルーピングの仕方に差が出るのは当然のことです。そこを埋めてくれる機能を果たすことはチーム開発においてとても良いことです。デメリット理解が難しいファイル数・コード量が増える開発コストが高いことがクリーンアーキテクチャのボトルネックです。先述したPresenterが一例にあるように、Presenter(インターフェース)-PresenterImpl(実装)、UseCase-UseCaseImpl、Repository-RepositoryImpl、......、と、ただ役割を分割するだけでも多くなるファイル数・コード量にそれぞれインターフェースを切り出して書く必要が出てきます。長期にわたる開発・メンテナンスが必要になるとき複雑な機能を有するアプリを開発するときテストを重視した開発のとき長期というのは、クリーンアーキテクチャを案件に導入してみたことのある人々の間でだいたい1年以上と考えてもらうと差し支えないかなという話がされています。期間のみならずどれだけ複雑な機能がアプリに含まれているかなどを考慮に入れて、もう少し短い期間ではあるけれど導入してみようという判断でも良いと思います。短納期の開発のときメンテナンスする予定のない開発のとき作りがシンプルなアプリの開発のとき短納期での開発やそもそもテストをしっかりとは回さないような場合にはクリーンアーキテクチャは向いていません。Routing)での実装Wireframe(VIPERにおけるRouting)という役割をApplication層に追加したクリーンアーキテクチャの派生系です。UIViewControllerのpresentなどの画面遷移の設計上、「ViewControllerがViewControllerのことを知っている(=依存している)」状況が発生しがちです。この部分を疎結合にし、ViewController同士がそれぞれを知ることなく画面遷移を行えるようにする役割がWireframeになります。元々のクリーンアーキテクチャを採用する余裕がある状況であればこのパターンは採用しても良いと、個人的には思っています。元々のクリーンアーキテクチャ同様にテストを行う前提で、長期にわたる開発が行われる場合でない場合には利用すべきではないパターンになります。DIでの実装DIを考慮しない、テスタビリティを度外視した実装。このパターンでは各役割ごとの独立性を切り捨てます。具体的には各役割間でのインターフェース(protocol)を捨てた実装のことを指し、その箇所はクロージャを用いて実装します。}}「それってもはやクリーンアーキテクチャではないのではないか?」と思われるかもしれませんが、おそらくその通りです。クリーンアーキテクチャにおけるテスタビリティを意識するような要素はありません。私はこれが悪いことばかりであるとも考えていません。このパターンがクリーンアーキテクチャのもつ高いテスタビリティ以外のメリットを未だ持っているからです。「テストを回したりするような余裕はないが、複雑な仕様のアプリを作らなければいけないとき」に利用すると良いと考えています。クリーンアーキテクチャの「チームメンバーの設計認識を統一できる」メリットを享受でき、「依存の単一方向性が守られている」ことによりシンプルな作りにできているからです。ここで言うシンプルという言葉を補足すると、データと処理の流れが追いやすい状況を指しています。これはソースコードの可読性を高めてくれます。利用すべきでない状況このパターンの冒頭で述べたように、各役割の依存性が高くなっておりテストはとてもやりづらいです。そのためテストを行う必要のある状況では向いていません。まとめクリーンアーキテクチャとその派生系となるものを試してみたという紹介をしました。DIパターンという三つのパターンがありました。それぞれに向き不向きや検討不足の部分もあるかと思いますが、今後の開発の参考になれば幸いです。「こんなに多くの役割に分けて、インターフェースやテストを考慮しなければならないほどにiOSアプリ開発も複雑な要求をされるようになったんだなあ」と人が話しているのを聞きました。インターフェースを考慮して、ここまで細かな設計をして〜という流れは、そういえば業務系のシステム開発では昔から取り入れられていたものだったという父の話を思い出しました。私の父もエンジニアで業務系システムを書く人間なのですが、私がプログラミングを始めた頃にこんな言葉をもらいました。当時は学び始めて間もなく、プログラミングどころか「ぷよぐやみんぐ」程度にしか理解のなかった自分にはその言葉の意味は全く理解できていませんでしたが、今年に入ってOSSライブラリを作ってみたり、こうやってクリーンアーキテクチャに触れてみるようになってその言葉の重さを痛感しました。いやぁ、インターフェースまじ大事。今後もより理解を深めていこうと思います。1,470,002ダンボールの人。最近はJavaScriptやってます。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。今日はオフィスに用があるので、通勤ラッシュを避けて出社しました。この子は新メンバーのさめくんです。在宅勤務が推奨されているのでオフィスが閑散としており、すこしさみしそうです。本が出ていたので読んでみたところよかったので紹介させていただきます。使いたいときの注意点を書きました。新井成一64最近Sphinxつかってドキュメントを書いてるのですがなかなかイケています。臼田佳祐295ワークフロー自動化OSSのn8nをAWS環境で建てて検証してみました。非常に期待できるサービスです。Fargateの勉強をしています。使ってみたい方は参考にしてください。洋介255SnowflakeがAWSの東京リージョン上で稼働するようになりました。データを日本に置けます。芳賀健232こんにちは!猫様の忠実なるしもべ、芳賀健です。Tokyoで開催されました。カフェ店長のオカノです。クラスメソッド株式会社が運営するAWS・iOS・HTML5に関する技術情報サイトです。