Swiftマルチモジュール構成ガイドライン

Note

このガイドラインは執筆中です。

マルチモジュール構成を推奨する理由

• 複数人/複数チームによる並行開発がしやすい
  • チームごとにモジュールを分担して開発することでコンフリクトを避けられる
• 機能責務の分離により、可読性、凝集性、保守容易性、変更容易性などが向上する
  • 複数機能が混在しないことでコンテキストに集中して開発できる
  • 例えば特定モジュールのみをインターフェースを変更せずにリファクタリングできる
• キャッシュがうまく効けば、ビルド効率が上がる

モジュールを作る時の心得

１つ１つのモジュールをOSSとして公開する気持ちでインターフェースを設計する

公開するインターフェースに制約を持たせる（推奨レベル強）

• 機能責務の分離を徹底し、モジュール間の癒着を無くす
  • モジュールを分けた意味がなくなる（ディレクトリを分けているだけと変わらなくなってしまう）
• 十分に抽象化されたデータ構造でインターフェースを構築する
  • 例として、標準SDKに存在するインターフェースだけでインターフェースを設計する（String、Int、URLなど）
  • 場合によってはswift-async-algorithmsのAsyncChannelなども該当するかもね
  • TCAのStoreとかRxSwiftのObservableようなライブラリの型に依存するものを使わない
• モジュールの提供する機能の抽象度と公開するインターフェースの抽象度を揃える
  • モジュールの提供する機能が画面やUIコンポーネントの場合、基本的には、インターフェースとして公開するものはViewやViewModifierにする
    • 例えばモジュールAがモジュールBのViewを使う時はViewだけとやりとりする
    • モジュールBのモデルを直接呼び出したりはしないようにする

モジュールごとにリソースを持つ（推奨レベル弱）

• モジュール内で機能責務を完結する
• 一方で、「OK」「キャンセル」みたいな普遍的な文言、全体で統一したいカラーパレットなどが分散重複する🤔
• デザインシステムレベルのもの（カラーパレットとか）はそれ自体がライブラリとして存在していて、それをコンテキストリソースに変換するのをモジュールでやればいい

どうモジュールを切るのがいいか？（考え中）

開発組織の規模によって推奨の方法が変わる

• 機能ごと（複数チームで開発なら推奨レベル強、チーム開発なら推奨レベル中）
  • 凝集性に貢献する
  • １つの機能とは？という境界線を見極める練度が必要
• 画面ごと（推奨レベル中）
  • ベターだけどベストじゃない
  • 結局複数機能が混ざったFat ViewControler問題を抱える
• レイヤー（Data、Domain, Presentationとかそういう層）ごと（1人~2人の場合に推奨）
  • コードの書き方の一貫性を保つ効果がある
  • 機能との掛け合わせがあれば凝集性も落ちない