DDD Context mapで全体分析し、iOSアプリをマルチモジュール構成に変更した話
こんにちは、Takahiroです。今回はiOSアプリをマルチモジュール構成にしたお話をご紹介します。
※本投稿では、内容の簡潔さのためDDDの正確な説明は省略させていただきます。
背景：急速にスケールするプロダクト
PROGRITでは、効果的に英語を習得するために目的に応じてプロダクトをローンチしています。現在では、以下の4プロダクトを提供しています。
基本的にはiOSとAndroidの両方のモバイルアプリを提供しています（※）。
※ディアトークはiOSのみ、スピフルはWebアプリとして提供しています
つまり、合計7個のモバイルアプリの運用が必要です！
この様にプロダクトが急速にスケールしている状況において、開発と保守の効率化が急務となっています。
コード重複の問題
複数のプロダクトにおいて、体感で分かるほどコード重複が増えたと感じる時期がありました。
ユーザー認証、認可基盤へのリクエスト
サブスクリプション関連の処理
似た様なUIコード
トリガーとしては、新しくプロダクトを『0→1』でローンチしたタイミングになります。上記の内容が『重複しているなぁ、、、』と感じつつ、まずは市場投入してお客様へ価値を提供するという点にフォーカスしました。
この時、全く方針も無しで重複を見逃すわけにはいかないので、後の仕組みづくりを意識し『プロダクト間で処理を同じにする』という取り決めを徹底しました。その結果、共通化は比較的、簡単にできそうであり、故に『時間を確保して作業するだけ』という状況を作り出せました。
いざローンチが済み、今後のスケーラビリティのAsIs-ToBeを考えた際に、コード重複の問題へ改めて向き合いました。技術負債への投資か？ユーザー価値への投資か？
難しい意思決定をするため、戦略的に問題に向き合う必要が出てきました。
コンテキストマップによる分析
そこで選んだ手段がコンテキストマップ（※）による分析でした。
※ビジネス全体像と、システム全体像の構造分析をするイメージです
プロダクトの概念境界をドメイン構造と捉え（Problem Space）、サーバーのアプリケーション構成とモバイルのアプリケーション構成を境界づけられたコンテキストと捉えました（Solution Space）。
境界づけられたコンテキスト
バックエンドエンジニアの方々と協力して1時間ほどSolution Spaceをモデリングしました。俯瞰で重要な部分だけにフォーカスすると、以下の様な図になります。
このFACTを受け、私たちは『認可認証基盤』『サブスクリプション』の2つが効果的だと結論づけました。
抽象目線でコード重複が大きい
汎用性が高い＋ビジネス上も非常に重要
作業規模もさほど大きく無い
ユーザー価値への投資と無理なく共存できる体制の見通しも立ち、技術改善を実行しました。
共有モジュールの切り出し
前述の2つの機能を共有モジュールに切り出した後のToBe像が以下です。
実際の実装は、モバイルアプリがマルチモジュール構成となり1つのパッケージとして配信されますが、問題解決の目線においては『モバイル共有モジュール』という形でコンテキストを分離しました。
ビジネス上の重要、かつクリティカルなコードの重複を排除し、コードの一貫性を担保できる構成にすることは、単に開発の生産性向上だけでなく、信頼性の面においてもベネフィットがありますね。
マルチモジュール構成への変更
手段としては、共有モジュール用のGithub-repositoryを作成し、各プロダクトのコードから『git-submodule』で参照する形としました。
これにより、エンジニアはあたかもプロダクトのコードの一部の様に開発、デバッグができますが、その結果の反映は全プロダクトに伝播できる様になりました。
1アプリ2000行の重複除去に成功！
iOSアプリを先行対応した結果、2000行のコードが共有されました。複数のプロダクトに導入するので、数千行の保守コードが削減され、一元管理できる様になったということです！
プルリクエストのレビュー体制は以前よりも複雑になりますが、上記の保守性の向上のベネフィットと天秤にかけると、今回の取り組みは価値があったなと自信を持って言えます。
Androidアプリも同様に共有モジュール化によって保守性が向上しますし、KMPを利用すれば掛け算的に生産性が上がることも見えてきました！
今後の展望
共有モジュールの基盤を拡充していく
今回、スモールスコープで仕組みづくりをしたという捉え方もできます。今後、価値提供とのバランスを見つつ、重複するコードを順次移行していくことで、開発生産性の最大化に取り組みます。
KMP導入のPOCを進めていく
技術的には更にハードルは高くなりますが、iOS / Androidでのクロスプラットフォームでの共有モジュール化も検証していきます。単に技術的な問題だけではなく、組織的な体制や学習曲線などクリアすべき課題は多いですが、素早く高品質なプロダクトをご提供するため、積極的に挑戦します！
よりユーザー価値に近い設計を目指す
今回は比較的分かりやすい『汎用的な機能』を共有モジュール化しました。今後は、より深くドメインに関わる機能を切り出しを目指します。
それはモバイルエンジニアが単独で行うことではなく、サーバーサイドの対応、PdMと連携しドメイン自体のリファクタリングも必要になるかもしれません。
その様にしてProblem Spaceが再構築され、適切にプロダクト間で再利用されれば、使って頂くユーザー様の価値を最大化できると考えます。
プログリットの成長を加速させる仲間を募集しています！
プログリットでは、プロダクト開発のメンバーを募集しています！
「世界で自由に活躍できる人を増やす」というミッションに共感してくださる方、組織の中でお互いに切磋琢磨しながら成長していきたいという方は、ぜひカジュアル面談でお話しましょう！
この記事が気に入ったらサポートをしてみませんか？