モバイル開発におけるSeparation of Concerns — その概要、原則、適用

Separation of Concernsとは

Separation of Concernsは、ソフトウェアシステムを独立した部分に分解し、それぞれが1つのタスクを解決するという原則です。concern（責任領域）という用語は、機能性の分離可能な任意の部分（画面表示、タップ処理、データ検証、ネットワーク通信）を指します。この原則は、ある領域の変更が他の領域の変更を必要としないようにコードをグループ化することを指示します。

モバイル開発では、SoCは複数のレベルで現れます：アプリケーションを画面に分割することから、単一クラス内のコード編成まで。ネットワークからデータをロードし、JSONを解析し、UIをレンダリングするActivityやViewControllerは、Separation of Concernsに違反しています — そのようなコードは保守、テスト、拡張が困難です。代替案は、各責任を個別のコンポーネントに抽出することです。

この原則は抽象化の概念と密接に関連しています：各レイヤーは厳密に定義されたインターフェースを提供し、実装の詳細を隠蔽します。これにより、開発者はUIロジックを書き換えることなく、ネットワークライブラリやデータベースを交換できます。これは、要件や技術が時間とともに変化する長期的なプロジェクトで特に価値があります。

原則の歴史と起源

Edsger Dijkstraは、1974年の論文「On the Role of Scientific Thought」でSeparation of Concernsのアイデアを初めて定式化しました。彼は、ソフトウェアシステムの複雑さは、システムを分離して分析される部分に分割することで制御できると主張しました。このアプローチは、コードが計算、入出力、ユーザーインターフェースを混在させていた当時のモノリシックなプログラムとは対照的でした。

1980年代には、このアイデアは構造化プログラミングの支持者によって発展させられ、その後オブジェクト指向アプローチによって発展しました。SmalltalkやC++などの言語は、SoCを実用的なツールにするカプセル化とモジュール性のメカニズムを提供しました。現代のアーキテクチャパターン — MVC、MVP、MVVM、Clean Architecture — は、Separation of Concernsの原則を直接具現化したものです。

モバイル開発の世界では、AppleはiOSの標準としてMVCを推進し、Model-View-Controllerがデータ、表示、制御ロジックを分離しました。GoogleはAndroid向けにViewModelとRepositoryに基づくアーキテクチャガイドラインを提案しました — 各コンポーネントは独自の限定されたタスクを解決します。SoCなしでは、モバイルアプリケーションはMassive View Controller — 何千行ものクラス — に変わり、変更がすべての機能を壊すリスクがあります。

モバイルアーキテクチャにおける分離のレベル

4つの主要レイヤーが、Separation of Concernsを実装する典型的なモバイルアプリケーションアーキテクチャを形成します。各レイヤーは自身のドメインのみを担当し、インターフェースを介して隣接レイヤーと相互作用します。

UIレイヤー：ViewとViewModel

Viewは、データの表示とユーザーイベントの処理のみを担当します。iOSではUIViewControllerとUIView、AndroidではFragmentまたはActivityです。ViewModelは画面の状態と、データを表示用の形式に変換するロジックを含みます。分離により、UIKitをSwiftUIに置き換えたり、Jetpack Composeで画面を書き換えたりしても、ビジネスロジックに影響を与えないことが保証されます。

ViewModelのテストにはエミュレータやシミュレータの実行は不要です — データ変換とユーザーアクションへの応答を検証する単体テストで十分です。これはSeparation of Concernsの直接的な結果です：UIはビジネスルールと混ざらず、各コンポーネントは分離してテストされます。

ビジネスロジックレイヤー：ユースケースとインタラクター

ユースケース（またはインタラクター）は、アプリケーションのビジネスルール（計算、検証、データ呼び出しのオーケストレーション）を含みます。このレイヤーはUIやプラットフォームフレームワークの存在を知りません。ユースケースはRepositoryからデータを受け取り、ロジックを適用し、完成した結果をViewModelに返します。分離により、1つのユースケースを異なる画面で再利用できます。

たとえば、LoginUseCaseはメールの有効性をチェックし、認証のためにAuthRepositoryを呼び出し、結果を返します。ログイン画面の見た目（SwiftUI、UIKit、Compose）には依存しません。ビジネスルールが変更された場合、UIやデータベースに触れることなく1つのユースケースを修正するだけで十分です。

データレイヤー：RepositoryとDataSource

Repositoryはデータソース（リモートAPI、ローカルデータベース、メモリキャッシュ）を抽象化します。ViewModelとユースケースはデータがどこから来るかを知りません — Repositoryがネットワークからロードするかキャッシュからロードするかを決定します。この分離により、ビジネスロジックやUIに影響を与えることなくストレージの実装を変更できます。

DataSourceはさらに低レベルの分離です：NetworkDataSourceはHTTPリクエストのみを担当し、LocalDataSourceはRoomやCoreDataとの連携を担当します。Repositoryは異なるDataSourceへの呼び出しを単一の一貫したインターフェースに結合します。各DataSourceはモックやフェイクサーバーを使用して独立してテストされます。

DataSourceレイヤーの適切な実装により、データベーススキーマの変更やREST APIのGraphQLへの置き換えは1つのDataSourceにのみ影響し、Repositoryやその消費者には影響しません。これはインフラストラクチャレベルでのSeparation of Concernsの直接的な結果です：各技術的関心事は分離され、カスケード変更なしで交換可能です。

デザインパターンにおけるSoC

MVVM（Model-View-ViewModel）はモバイル開発で最も人気のあるパターンであり、Separation of Concernsを直接実装しています。Modelはデータとビジネスロジックを含み、Viewは表示を担当し、ViewModelはリアクティブメカニズムを通じてそれらを接続します。Flutterでは、BLoCがイベント、状態、ビジネスロジックへの分離とともに同様の役割を果たします。

Robert Martin（アンクル・ボブ）のClean Architectureは、SoCを最大限に引き出します：システムは独立したリング（エンティティ、ユースケース、アダプター、フレームワーク）に分割されます。内部リング（エンティティ）は外部リング（フレームワーク）に依存しません。これにより、アプリケーションのコアロジックを書き換えることなく、データベース、UIフレームワーク、さらにはプラットフォームを変更できます。

実際には、モバイルプロジェクトが完全なClean Architectureを実装することは稀です — ほとんどのアプリケーションには3層アーキテクチャで十分です：UI、ドメイン、データ。ドメインレイヤーはユースケースとビジネスモデルを含み、Android SDKやiOS SDKから完全に分離されています。この分離により、20%の労力で80%の利益が得られます。

// Data layer — データ取得のみを担当
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — ビジネスロジック、APIやデータベースを知らない
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — 表示のみ
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

上記のコードは純粋な分離を示しています：UserRepositoryはAPIとのみ連携し、GetUserNameUseCaseは名前フォーマットのビジネスロジックを含み、UserViewModelはUI状態を管理します。各クラスには変更理由が1つあり、それがSeparation of Concernsの本質です。

Separation of Concernsの利点と限界

SoCの主な利点は保守性です。独立したレイヤーに分割されたコードは分析が容易です：開発者はエラーが発生したレイヤーのみを見て、他のレイヤーに気を取られません。長期的なプロジェクトでは、モノリシックコードと比較してバグの発見と修正時間が30～50%削減されます。

2つ目の重要な利点はテスト容易性です。ビジネスロジックがUIやフレームワークから分離されている場合、エミュレータを実行せずに単体テストでカバーできます。単体テストのカバレッジが高いAndroidおよびiOSプロジェクトでは、新機能追加時のリグレッションが大幅に少なくなります。

主な限界は複雑性の増大です。マイクロレイヤーと抽象化への過度な細分化により、単純なボタンを追加するために開発者が5つのファイルを編集する必要が生じます。Separation of Concernsの原則は合理的なバランスを必要とします：実際に独立して変化する領域のみを分離します。小規模プロジェクトでは、追加の抽象化なしでUI、ロジック、データへの基本的な分離で十分です。