iOS Clean Architecture を採用した振り返り
目次
- クリーンアーキテクチャとは
- 採用した背景
- アプリの構成
- 開発してみて
- 最後に
クリーンアーキテクチャとは
レイヤーアーキテクチャの一種で、ソフトウェアをレイヤーに分離し、依存性ルールに従うことで、テスト可能なシステムを作成することができる。 データベースやWebフレームワークのように、システムの外部部分が陳腐化しても、それらの陳腐化した要素を最小限の手間で置き換えることができる。
ことを利点としている。
採用した背景
新しく0からiOSアプリを開発する際に0からアーキテクチャ選定をする機会があった。
その際に以下の2点を選定する判断基準とした。
- 長期的にメンテナンスできること
- 人の出入りがあってもすぐに開発できるようになるべく学習コストを下げる
Clean Architecture は
- レイヤーを分けてテスト可能にしやすいこと
- Rxなどの学習コストが高いライブラリを使わずに開発を行えること
から採用に至った。
アプリの構成
root/ ├ App/ │ ├ Infra/ │ ├ Presenter/ │ ├ Storyboard/ │ ├ UseCase/ │ ├ ViewController/ │ └ ViewModel/ └ Domain/ ├ Entity/ ├ Repository/ ├ Service/ └ ValueObject/
またライブラリを最低限しか使わないようにしたかったので、
並列処理には dispatchGroup
、通信には URLSession
を使うなど自前で実装をした。
最初作るときは設定が必要だが、Swiftのバージョンをあげる際にライブラリ側の対応を待つ必要があるため、後々のことを考えると良い選択だったと思う。
開発してみて
クリーンアーキテクチャを採用してよかった点は、
- テスト可能な構成にできたので高い品質で開発できた点
- 業務知識をDomain層に集めることができて、似たようなコードがいろいろなところに出てくることはなくなった
- 機能の変更をするときは変更を局所化できる
逆に悪かった点は
- レイヤーを分けるため、作成するファイル数やコード量が増える
- 新しい機能を作るときは修正量が多く時間がかかる
のようになっています。
ファイルごとに役割が明確になるため、品質が高まり機能の修正はしやすいが、 新機能を0から作るときはコード量が多く時間がかかってしまった。
最後に
まだ人が集まっていないアプリを開発する場合は、1秒でも早くリリースしたいと思うので、最初からクリーンアーキテクチャを採用する必要はないと思いますが、
ある程度のユーザが使うことが想定されていたり、高い品質を最初から要求したい場合は採用するのを検討すると良いと思いました。