Zenn
👻

クラシルリワードの構成とそれぞれの責務

2025/01/27に公開

はじめに

こんにちは、tattsun です 🙌
この記事では、クラシルリワード iOS の構成と、それぞれのコンポーネントがどのような責務を担っているのかを詳しくご紹介します。設計や実装の背景を知りたい方にとって、参考になる内容をお届けできればと思います。

さらに詳細な情報については、こちらの記事もぜひご覧ください 🙇
https://tech.dely.jp/entry/2023/05/30/113128

背景

Swift 6 対応を進める中で、クラシルリワードのどの部分を MainActor として扱うべきかを明確にする必要がありました。これは、Strict Concurrency 対応時に発生するコンパイルエラーを解消する際、基準を定めることが難しかったためです。

この課題に対応するため、各コンポーネントの責務を整理し、MainActor で隔離すべき箇所を再考しました。また、時間の経過やメンバーの入れ替わりによって初期設計との乖離が生じていたため、チーム全体で認識を統一することも重要な目的でした。

目的

上記の背景を踏まえて、今回の目的は以下の通りです。

  • クラシルリワードの構成と各コンポーネントの責務を明確化する
  • ドキュメントにし、誰でも閲覧・編集が出来る状態にする

クラシルリワードの構成

まずは、現状の構成を確認します。


現状のクラシルリワードの構成

一見すると大きな問題はないように見えますが、以下のような疑問が浮かび上がりました。

  • Service と Manager の命名規則が不明確
  • Service / Manager の役割と責務の範囲が曖昧
  • Service / Manager で Store を参照することの妥当性

これらの課題についてチームで議論した結果、Manager を廃止し、すべて Service に統一するという結論に至りました。この変更により、命名規則の統一と責務の明確化を実現し、構成の意図をチーム全員が共有できるようになりました。

最終的な構成は以下の通りです。


新しいクラシルリワードの構成

今回の変更は一見すると小さな違いに見えるかもしれませんが、命名規則の統一はコードベースの可読性と保守性を大きく向上させる重要な改善です。また、これを機に各コンポーネントの責務が再確認され、チーム開発の効率化にも繋がることが期待されます。

それぞれの責務

曖昧なままにしておくと、時間が経つにつれてさらなる乖離を招き、新しいメンバーが参画した際には独自の解釈で開発が進んでしまう可能性があります。その結果、プロジェクト全体の整合性が失われ、開発効率が低下するリスクが高まります。

チームの規模が拡大している現状では、このような問題を未然に防ぐためにも、各コンポーネントの責務を明確に定義し、ドキュメント化して共有することが不可欠です。幸いにも、クラシルリワードの立ち上げ時から在籍しているメンバーの協力を得られたため、当時の設計意図を確認しながら、以下のように整理を進めました。

名称 責務
RouterService アプリのライフサイクルの管理を行う
ScreenRequest 画面遷移を行う際のインターフェース
Builder 依存を解決して ViewController を返却する
ViewController 画面遷移の制御を主に行う
View 画面の見た目を表現する
ViewModel View, ViewController で利用するロジック群
ViewData View で利用する情報をまとめた構造体
Service モジュールを跨いだ処理の共通化
MainActorで処理する必要がないロジックを管理する(状態を持たない)
Dispatcher Store へ書き込みとデータの加工などを行う
Storeと1対1の構造になる
Store アプリ全体で使用する状態を管理する
Dispatcher以外から書き込みは行えず、読み取りのみ可能
Dispatcherと1対1の構造になる
Repository API通信を行い、アプリ内で利用するための構造体に変換する
Entity APIから受け取ったデータをアプリ内で利用するための構造体

明確化の成果と今後の展望

今回の整理により、各コンポーネントの責務が明確になり、チーム内で統一された認識を持つことができました。これにより、新しいメンバーの参画時にも設計意図を正しく共有でき、開発効率とコードの一貫性が向上することが期待されます。また、この基盤をもとにどの範囲を MainActor として扱うべきかについても整理しましたが、詳細は別の記事でご紹介する予定です。ぜひそちらもご覧ください!

一方で、今回の取り組みが完成形ではありません。プロダクトやチームの成長に応じて設計を見直し、継続的に改善を重ねることが必要です。この新しい構成を基盤に、より良いプロダクトを作り上げていきたいと思います。

まとめ

この記事では、クラシルリワード iOS の構成と責務を整理する取り組みについてご紹介しました。命名規則の統一や責務の明確化によって、アーキテクチャ全体の整合性を向上させるだけでなく、今後のチーム開発における課題解決の土台が築けたと感じています。

設計は一度決めたら終わりではなく、常に見直しと改善を行う必要があります。この経験が、他のプロダクトや開発チームの参考になれば幸いです 🙌

最後までお読みいただき、ありがとうございました!

dely Tech Blog

Discussion

ログインするとコメントできます