2021 / 12 / 22

開発速度向上のためのAnewsモバイルアプリのアーキテクチャ改善

はじめに

こんにちは、Anewsのエンジニアリングマネージャーの山崎です。
この記事はストックマークアドベントカレンダーの22日目の記事です。

普段は、エンジニアリングマネージャーとして開発体制や中長期のエンジニア戦略を考えています。またエンジニアリングマネージャーとは別にエンジニアとしてAnewsのFlutterアプリの開発を行なっています。

Anewsの開発組織では全員がフルスタックエンジニアとして働くことを推奨しており、開発体制やプロセスについてもフロントエンド、バックエンドなどの領域を意識せず顧客への価値提供を最大化するためエンジニアが必要な開発を行うようにしています。

その中で、モバイルアプリだけは固定されたメンバーで開発を行うような体制になっています。
理由としては、
・モバイルアプリの開発経験が少ない
・モバイルアプリのコードが複雑になっており、学習コストが高くなっている

この問題を解決するために未経験者でも開発が行いやすいようにするため、モバイルアプリのアーキテクチャを見直すことにしました。

今回は現在行なっているアーキテクチャ刷新の全体像を紹介できればと思います。

現在の問題点

現在のアーキテクチャ問題点について
・開発ルールがないため個々のエンジニアの裁量で設計が決まっていく
・コード全体で依存関係が整理されておらず処理を追うことが難しい
・コードの結合度が高くコード改修での影響範囲が広くなる

この問題を解決するためにレイヤードアーキテクチャを採用し、階層ごとに処理を分割しUI部分についてはAtomic Designのコンポーネント分割を参考に分割することで影響範囲や処理のルールがわかりやすいようにしています。

全体のアーキテクチャの方針

UI, Domain, Infrastructureの３層構造にすることにより、依存関係を整理し影響範囲をわかりやすくしました。

UI：表示処理を行うコンポーネント
Domain：UIとは切り離されたビジネスロジックの集合
Infrastructure: 外部リソースとの接続処理の集合

ディレクトリ構成もレイヤーにより分割することにより、ディレクトリ内に含まれているコードの予想ができ探しているコードを見つけやすい状態にしています。

Domain, Infrastructureの方針

DomainとInfrastructureではAPIやSharedPreferenceなど外部リソースへのアクセスについての処理を全て担うことによりデータ生成の処理などを集約しAPIの変更を吸収できるようにしています。これにより、マスターデータの取得など各所で散らばりやすい処理の管理を容易にしています。

Domainに処理が集中することにより、UIでロジックを書くことが少なくなりUIでは表示のための処理に集中できるようになります。

UIアーキテクチャの方針

AnewsではAtomic Designを取り入れているため、Atomic DesignをベースにPage, Organism, Molecule, Atomの４つのコンポーネントでモバイルアプリ上でUIパーツを管理します。
依存関係は、Page → Organism → Molecule → Atomの順になっており、下位から上位のコンポーネントを見ないように依存関係が混沌としないようにしています。

また、更新、データ取得などページに関わるロジックについては、全てPageのコンポーネントが管理を行うようにしPageを見るとコンポーネントの更新とデータ取得について理解できるような設計を行なっております。この様にすることで、最初に見るべきコードをPageに絞ることでエンジニアがコードの全容を理解しやすいようにしています。

今後について

上記の設計をベースに、既存アプリの置き換え業務を行なっております。一筋縄ではいかない部分もありますが、アプリ開発を行なっているメンバーからも意見をもらいながら一緒に作り直しており、2022年初頭にはリリース予定となっております。

最後に

ストックマークでは一緒に働くメンバーを絶賛募集中です！Anews開発メンバーも募集していますので、ご興味があれば採用ページをご覧いただければと思います！