モバイルアプリ開発の基盤を作る！レイヤードアーキテクチャ入門

スマートフォンが私たちの生活に欠かせないものとなり、モバイルアプリ開発の需要はますます高まっています。しかし、ただ動くアプリを作るだけでは十分ではありません。ユーザーが増え、機能が複雑化していく中で、メンテナンスしやすく、変更に強く、テストしやすいアプリを開発することが、長期的な成功の鍵となります。🔑

そこで重要になるのが「アーキテクチャ（設計）」です。アーキテクチャとは、いわばアプリの設計図であり、コードをどのように整理し、各部分がどのように連携するかを定めるルールです。適切なアーキテクチャを採用することで、開発者は複雑さに立ち向かい、品質の高いアプリを持続的に開発できるようになります。

数あるアーキテクチャの中でも、最も基本的かつ広く理解されているのが「レイヤードアーキテクチャ（Layered Architecture）」です。今回は、このレイヤードアーキテクチャの基本的な考え方、メリット・デメリット、そしてモバイルアプリ開発でどのように活用できるかについて、順を追って丁寧に解説していきます。初心者の方でも理解できるよう、専門用語はなるべく避け、具体的なイメージが湧くように説明します。✨

この記事を読めば、以下の点が理解できるはずです。

• レイヤードアーキテクチャの基本的な概念
• なぜ層（レイヤー）に分ける必要があるのか（メリット）
• 各層がどのような役割を担っているのか
• モバイルアプリ開発でレイヤードアーキテクチャを考える際のポイント

さあ、一緒にレイヤードアーキテクチャの世界を探検し、より良いアプリ開発への第一歩を踏み出しましょう！🚀

レイヤードアーキテクチャは、その名の通り、アプリケーションの機能を複数の「層（レイヤー）」に分割し、それらを積み重ねて構成する設計手法です。まるでケーキ🍰や地層のように、各層が特定の役割を担い、全体として一つのアプリケーションを形成します。

このアーキテクチャの根底にある重要な考え方は「関心の分離 (Separation of Concerns – SoC)」です。これは、プログラムの異なる関心事（目的や機能）を、それぞれ独立したモジュール（ここでは「層」）に分割するという原則です。例えば、「ユーザーに情報を表示する」という関心事と、「データベースにデータを保存する」という関心事は、性質が全く異なります。これらを混ぜこぜにしてしまうと、コードが複雑になり、修正やテストが困難になります。

レイヤードアーキテクチャでは、これらの異なる関心事を層として分離することで、以下のようなメリットを目指します。

• 変更の影響範囲を限定する: UIのデザインを変更しても、ビジネスロジックやデータアクセス方法に影響を与えにくくする。
• 再利用性を高める: 特定の層の機能（例えば、データアクセス処理）を、他の部分や別のアプリケーションで再利用しやすくする。
• テストを容易にする: 各層を独立してテストできるようにする。
• 開発の分業をしやすくする: UI担当、ロジック担当、データベース担当など、専門分野ごとに開発を進めやすくする。
• コードの可読性と保守性を向上させる: コードの構造が明確になり、どこに何が書かれているか理解しやすくなる。

では、具体的にどのような層に分けるのでしょうか？最も一般的で基本的な構成は、以下の3つの層からなる「3層アーキテクチャ」です。もちろん、アプリケーションの規模や複雑さに応じて、さらに細かく層を分けることもあります。

1. プレゼンテーション層 (Presentation Layer) / UI層
2. ビジネスロジック層 (Business Logic Layer) / ドメイン層 (Domain Layer)
3. データアクセス層 (Data Access Layer) / インフラストラクチャ層 (Infrastructure Layer)

これらの層が、どのように連携し、アプリケーション全体を構築していくのか、次のセクションで詳しく見ていきましょう。

レイヤードアーキテクチャの核心は、各層が持つ明確な役割と責務（責任範囲）です。ここでは、基本的な3層構造を例に、それぞれの層が何を担当するのかを詳しく見ていきます。

1. プレゼンテーション層 (Presentation Layer / UI Layer) 🖼️

プレゼンテーション層は、ユーザーが直接触れる部分、つまりアプリケーションの「顔」となる層です。主な責務は以下の通りです。

• ユーザーに情報を分かりやすく表示する（画面レイアウト、テキスト、画像など）。
• ユーザーからの操作（タップ、スワイプ、入力など）を受け付ける。
• 受け付けた操作や入力データを、下位層（ビジネスロジック層）が理解できる形式に変換して渡す。
• 下位層から受け取った処理結果を、ユーザーに表示する形式に変換して画面に反映する。

モバイルアプリ開発における具体例としては、以下のようなものがこの層に対応します。

• Android: Activity, Fragment, View, Jetpack Compose の Composable 関数, XML レイアウトファイル
• iOS: ViewController, View, Storyboard, SwiftUI の View
• クロスプラットフォーム (React Native, Flutter): Component, Widget

⚠️ 注意点:

この層には、原則としてアプリケーション固有のビジネスロジック（計算、判定、データ加工など）を含めるべきではありません。例えば、「ユーザーが入力したパスワードが有効かチェックする」「商品の合計金額を計算する」といった処理は、プレゼンテーション層ではなく、ビジネスロジック層が担当すべきです。UIの関心事は、あくまで「どのように見せるか」「どのように操作を受け付けるか」に留めるべきです。

プレゼンテーション層がビジネスロジックを持つと、UIの変更がロジックに影響を与えたり、同じロジックが複数の画面に分散して重複したりする原因となります。

2. ビジネスロジック層 (Business Logic Layer / Domain Layer) 🧠

ビジネスロジック層は、アプリケーションの「頭脳」とも言える最も重要な層です。この層は、プレゼンテーション層から依頼を受け、アプリケーションが実現すべき本来の機能（ビジネスルールやドメインロジック）を実行します。主な責務は以下の通りです。

• アプリケーション固有のルールに基づいて、データの妥当性を検証する（例：メールアドレスの形式チェック、パスワードの強度チェック）。
• 必要な計算やデータ加工を行う（例：消費税の計算、検索条件に基づいたデータフィルタリング）。
• 複数のデータソースからの情報を組み合わせて、意味のある情報を作成する。
• データアクセス層にデータの取得や保存を依頼する。
• 処理結果をプレゼンテーション層に返す。

この層は、特定のUIフレームワーク（Android SDKやUIKitなど）やデータストレージ技術（特定のデータベースなど）に依存しないように設計することが理想的です。これにより、UIやデータベースを変更しても、アプリケーションの中核ロジックへの影響を最小限に抑えることができます。

この層に対応する具体的なコンポーネント名としては、以下のようなパターンで実装されることが多いです。（これらはアーキテクチャパターンによって呼び方が異なります）

• UseCase (ユースケース): ユーザーが行う操作に対応する具体的な処理（例：「ユーザー登録を行う」「商品一覧を取得する」）。
• Interactor (インタラクター): UseCase とほぼ同義で使われることが多い。
• Service (サービス): 特定のドメインに関連するビジネスロジックを提供する。
• ViewModel / Presenter の一部: MVVMやMVPパターンにおいて、プレゼンテーションロジック以外の純粋なビジネスロジックを担当する部分。（ただし、ViewModel/Presenter はプレゼンテーション層に近い存在とみなされることも多い）
• Domain Object / Entity: アプリケーションの核となるデータ構造とその振る舞いを定義したもの。

💡 ポイント:

ビジネスロジック層は、アプリケーションの価値そのものを担う部分です。この層を他の層から独立させ、純粋なロジックに集中できるように設計することが、高品質なアプリ開発に繋がります。

3. データアクセス層 (Data Access Layer / Infrastructure Layer) 💾

データアクセス層は、アプリケーションが必要とするデータの供給源や保存先とのやり取りを一手に引き受ける層です。ビジネスロジック層からの指示に基づき、具体的なデータ操作を行います。主な責務は以下の通りです。

• データベース（SQLite, Realm, Core Dataなど）へのデータの保存、更新、削除、読み込み。
• ファイルシステムへのデータの読み書き。
• ネットワーク越しのAPI（REST API, GraphQLなど）との通信。
• SharedPreferences / UserDefaults などの設定情報の読み書き。
• ビジネスロジック層が扱いやすい形式にデータを変換する（例：データベースのレコードやAPIのレスポンスを、ビジネスロジック層で定義されたオブジェクトにマッピングする）。

この層の重要な役割は、「データソースの詳細を隠蔽する」ことです。ビジネスロジック層は、「ユーザー情報を取得したい」と依頼するだけでよく、そのデータがローカルのSQLiteデータベースにあるのか、リモートのAPIサーバーにあるのかを意識する必要はありません。データアクセス層がその詳細を吸収します。

これにより、例えば将来的にデータ保存方法をSQLiteから別のデータベースに変更したり、利用するAPIのエンドポイントが変わったりしても、ビジネスロジック層への変更を最小限に抑えることができます。

この層に対応する具体的なコンポーネント名としては、以下のようなものがよく使われます。

• Repository (リポジトリ): ビジネスロジック層に対して、データソースの種類（ローカルDBかリモートAPIかなど）を意識させずに、統一的なインターフェースでデータアクセスを提供する。キャッシュ戦略などを実装することも多い。
• DAO (Data Access Object): 特定のデータベーステーブルに対する CRUD (Create, Read, Update, Delete) 操作をカプセル化する。（主にローカルデータベースアクセスで使われる）
• API Client / Network Service: 特定のWeb APIとの通信ロジックを実装する。
• Data Source (データソース): Repository が内部で利用する、具体的なデータ取得・保存処理（ローカルDBアクセス、リモートAPIアクセスなど）を担当するコンポーネント。

✅ 利点:

データアクセス層を設けることで、データソースへの依存を局所化し、アプリケーション全体の柔軟性と保守性を高めることができます。テスト時には、実際のデータベースやネットワークに接続せず、この層をモック（偽のオブジェクト）に差し替えることで、ビジネスロジック層のテストを容易に行えます。

レイヤードアーキテクチャを効果的に機能させるためには、層と層の間の「依存関係」について、明確なルールを設けることが非常に重要です。

基本的な原則は、「上位層は下位層に依存しても良いが、下位層は上位層に依存してはならない」というものです。これを「一方向の依存関係」と呼びます。

先ほどの3層アーキテクチャで言えば、以下のようになります。

• プレゼンテーション層 は ビジネスロジック層 に依存する（利用する）。
• ビジネスロジック層 は データアクセス層 に依存する（利用する）。
• しかし、逆方向の依存は許されない。
  • ❌ データアクセス層がビジネスロジック層を知っていてはいけない。
  • ❌ データアクセス層がプレゼンテーション層を知っていてはいけない。
  • ❌ ビジネスロジック層がプレゼンテーション層を知っていてはいけない。

この一方向の依存関係を守ることで、以下のようなメリットが得られます。

• 影響範囲の局所化: 下位層の変更が上位層に影響を与えにくくなります。例えば、データアクセス層で使うデータベースを変更しても、ビジネスロジック層やプレゼンテーション層のコードを修正する必要がなくなります（インターフェースが変わらない限り）。
• 再利用性の向上: 下位層は上位層のことを知らないため、他のアプリケーションやシステムで再利用しやすくなります。
• 理解しやすさ: 依存関係が明確なため、コードの構造やデータの流れを追いやすくなります。

依存性逆転の原則 (DIP) について (少しだけ発展) 💡

より厳密な設計を目指す場合、「依存性逆転の原則 (Dependency Inversion Principle – DIP)」という考え方が導入されることがあります。これは、上位層が下位層の「具体的な実装」に直接依存するのではなく、両者が「抽象（インターフェースや抽象クラス）」に依存すべきだ、という原則です。

例えば、ビジネスロジック層がデータアクセス層を利用する際に、具体的な `SQLUserRepository` クラスに直接依存するのではなく、`UserRepository` というインターフェースに依存します。そして、`SQLUserRepository` はその `UserRepository` インターフェースを実装します。

# これはイメージです（Python風疑似コード）

# --- データアクセス層で定義 ---
class UserRepositoryInterface: # 抽象 (インターフェース)
    def find_user(user_id):
        raise NotImplementedError
    def save_user(user):
        raise NotImplementedError

class SQLUserRepository(UserRepositoryInterface): # 具体的な実装 (例: SQL)
    def find_user(self, user_id):
        # SQLを使ってユーザーを探す処理
        print(f"Finding user {user_id} from SQL DB...")
        return {"id": user_id, "name": "SQL User"}
    def save_user(self, user):
        # SQLを使ってユーザーを保存する処理
        print(f"Saving user {user['name']} to SQL DB...")

class InMemoryUserRepository(UserRepositoryInterface): # 別の具体的な実装 (例: メモリ)
    def find_user(self, user_id):
        print(f"Finding user {user_id} from memory...")
        return {"id": user_id, "name": "Memory User"}
    def save_user(self, user):
        print(f"Saving user {user['name']} to memory...")

# --- ビジネスロジック層で定義 ---
class UserService:
    # 具体的な実装ではなく、インターフェースに依存する！
    def __init__(self, user_repository: UserRepositoryInterface):
        self._user_repository = user_repository

    def get_user_name(self, user_id):
        user = self._user_repository.find_user(user_id)
        if user:
            return user["name"]
        return "User not found"

# --- アプリケーションの組み立て時 ---
# どの実装を使うかをここで決定（依存性の注入 - Dependency Injection）
sql_repo = SQLUserRepository()
# memory_repo = InMemoryUserRepository() # こちらに切り替えることも容易

user_service = UserService(user_repository=sql_repo) # または memory_repo

print(user_service.get_user_name(123))

このようにすることで、ビジネスロジック層はデータアクセス層の具体的な実装（SQLなのか、メモリなのか、APIなのか等）を全く知る必要がなくなり、より疎結合（そけつごう：コンポーネント間の結びつきが弱い状態）な設計を実現できます。これにより、下位層の実装を差し替えたり、テスト時にモックを注入したりすることが非常に容易になります。

DIP は少し複雑に感じるかもしれませんが、レイヤードアーキテクチャをより堅牢にするための重要な考え方の一つです。まずは「下位層は上位層に依存しない」という基本ルールをしっかり守ることから始めましょう。

これまでにも触れてきましたが、レイヤードアーキテクチャを採用することで得られるメリットを改めて整理してみましょう。これらのメリットを理解することで、なぜこのアーキテクチャが広く使われているのかがより明確になります。

レイヤードアーキテクチャは多くのメリットをもたらしますが、万能ではありません。採用する際には、いくつかのデメリットや注意点も理解しておく必要があります。

• 複雑性の増加: 非常に小規模なアプリケーションや、使い捨てのプロトタイプなどにとっては、層をきっちり分けることが過剰な設計（オーバーエンジニアリング）になる可能性があります。単純な機能を実現するために、層間のデータの受け渡しやマッピング処理など、本来不要な定型コード（ボイラープレートコード）が増えてしまうことがあります。
• コード量の増加: 各層の間でデータをやり取りするためのデータ転送オブジェクト（DTO: Data Transfer Object）や、インターフェース定義などが必要になる場合があり、全体のコード量は増加する傾向にあります。特に、層の数が増えれば増えるほど、この傾向は顕著になります。
• パフォーマンスへの影響（限定的）: 層間の呼び出しが増えることで、わずかながらパフォーマンスのオーバーヘッドが発生する可能性があります。ただし、現代のコンピューティング環境やモバイルデバイスの性能向上により、多くの場合、このオーバーヘッドは無視できるレベルです。ボトルネックとなるのは、多くの場合、ネットワーク通信やデータベースアクセス、複雑なUI描画など、層間の呼び出し自体よりも他の要因であることがほとんどです。
• 設計の難しさ: どの機能をどの層に配置すべきか、層の境界をどこに引くべきか、という判断は必ずしも簡単ではありません。特にビジネスロジック層とプレゼンテーション層の間で、どこまでがUI固有のロジック（状態管理など）で、どこからが純粋なビジネスロジックなのか、線引きが曖昧になることがあります。経験の浅い開発者にとっては、適切な設計を行うのが難しい場合があります。
• 「アンチパターン」に陥る危険性: ルールを破って下位層が上位層に依存してしまったり（依存関係の逆流）、一つの層が肥大化しすぎたり（例：Fat Controller, Fat ViewModel）、あるいは逆に層を細かく分けすぎて不必要に複雑になったりする「アンチパターン」に陥る可能性があります。

レイヤードアーキテクチャの考え方は、プラットフォーム（Android, iOS）や使用するフレームワークに関わらず適用できます。ここでは、それぞれのプラットフォームでどのようにレイヤードアーキテクチャの概念が適用されるか、簡単なイメージを見てみましょう。

注意: これらはあくまで一例であり、実際のプロジェクトでは、採用するアーキテクチャパターン (MVVM, MVI, VIPER, TCA など) によって具体的なクラス名や役割分担は異なります。

Android (Kotlin) の場合

Android開発では、Googleが推奨するアーキテクチャガイドラインがあり、レイヤードアーキテクチャに基づいたコンポーネントが提供されています。MVVM (Model-View-ViewModel) パターンと組み合わせることが一般的です。

• プレゼンテーション層 (UI Layer):
  • Activity / Fragment / Compose UI: 画面表示とユーザーイベントの処理を担当。
  • ViewModel (AndroidX ViewModel): UIの状態を保持し、UIに公開する。ビジネスロジック層 (UseCase) を呼び出し、結果をUIが監視可能な形式 (LiveData, StateFlow など) で公開する。UIロジック（表示形式の変換など）も一部担当することがある。
• ビジネスロジック層 (Domain Layer):
  • UseCase / Interactor: アプリケーション固有のビジネスルールを実行するクラス。通常、特定の処理（例: `GetUserUseCase`, `LoginUseCase`）を担当する。Repository からデータを取得し、加工や計算を行う。ViewModel から呼び出される。この層は Android フレームワークに依存しないプレーンな Kotlin/Java クラスで構成されることが理想。
• データアクセス層 (Data Layer):
  • Repository: ViewModel や UseCase に対して、データの取得・保存に関する統一的なインターフェースを提供する。内部で複数のデータソース（ローカル、リモート）を管理し、キャッシュ戦略などを実装する。
  • DataSource (Local / Remote): 具体的なデータアクセス処理を担当するクラス。
    • LocalDataSource: Room (SQLite), DataStore などを利用してローカルデータを操作。
    • RemoteDataSource: Retrofit, Ktor などを使ってリモートAPIと通信。
  • Data Transfer Object (DTO) / Database Entity: APIレスポンスやデータベースのテーブル構造に対応するデータクラス。

簡単なコードイメージ (ViewModel と Repository):

// --- データアクセス層 (Data Layer) ---
// Repositoryインターフェース
interface UserRepository {
    suspend fun getUser(userId: String): Result<User>
}

// Repository実装例
class UserRepositoryImpl(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) : UserRepository {
    override suspend fun getUser(userId: String): Result<User> {
        // 例: まずローカルキャッシュを確認し、なければリモートから取得するロジック
        val localUser = localDataSource.getUser(userId)
        if (localUser != null) {
            return Result.success(localUser)
        }
        return try {
            val remoteUser = remoteDataSource.fetchUser(userId)
            localDataSource.saveUser(remoteUser) // ローカルにも保存
            Result.success(remoteUser)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }
}

// --- ビジネスロジック層 (Domain Layer) ---
// UseCase例 (シンプルにするため今回は省略する場合もある)
class GetUserUseCase(private val userRepository: UserRepository) {
    suspend operator fun invoke(userId: String): Result<User> {
        return userRepository.getUser(userId)
    }
}

// --- プレゼンテーション層 (UI Layer) ---
// ViewModel例
class UserProfileViewModel(
    private val getUserUseCase: GetUserUseCase // または直接 UserRepository を使うことも
) : ViewModel() {
    private val _uiState = MutableStateFlow<UiState<User>>(UiState.Loading)
    val uiState: StateFlow<UiState<User>> = _uiState

    fun loadUser(userId: String) {
        viewModelScope.launch {
            _uiState.value = UiState.Loading
            getUserUseCase(userId)
                .onSuccess { user -> _uiState.value = UiState.Success(user) }
                .onFailure { error -> _uiState.value = UiState.Error(error.message ?: "Unknown error") }
        }
    }
}

// UI状態を表すクラス
sealed class UiState<out T> {
    object Loading : UiState<Nothing>()
    data class Success<out T>(val data: T) : UiState<T>()
    data class Error(val message: String) : UiState<Nothing>()
}

// (User, UserRemoteDataSource, UserLocalDataSource クラスの定義は省略)

iOS (Swift) の場合

iOS開発でも同様の考え方が適用できます。MVC (Model-View-Controller) が基本ですが、そのままでは Controller が肥大化しやすいため、レイヤードの考え方を取り入れた MVVM, VIPER, Clean Architecture などのパターンがよく採用されます。

• プレゼンテーション層 (Presentation Layer):
  • ViewController / SwiftUI View: 画面表示とユーザーインタラクションを担当。
  • Presenter / ViewModel: (MVP/MVVMの場合) ViewController/View からのイベントを受け取り、ビジネスロジック層 (Interactor/UseCase) を呼び出す。結果を受け取り、表示に適した形式に変換して ViewController/View に伝える。
• ビジネスロジック層 (Domain Layer / Business Logic Layer):
  • Interactor / UseCase: アプリケーション固有のビジネスロジックを実行する。Presenter/ViewModel から呼び出され、Repository を通じてデータを操作する。UIKit や SwiftUI には依存しない。
  • Entity / Domain Model: アプリケーションの中核となるデータ構造やビジネスルールを定義する。
• データアクセス層 (Data Layer / Infrastructure Layer):
  • Repository: ビジネスロジック層に対して、データ永続化やネットワーク通信の詳細を隠蔽するインターフェースを提供する。
  • Data Store / Service:
    • LocalDataStore: Core Data, Realm, UserDefaults, FileManager などを使ってローカルデータを操作。
    • RemoteDataStore / APIService: URLSession, Alamofire などを使ってリモートAPIと通信。
  • Data Transfer Object (DTO) / Managed Object: APIレスポンスやCore Dataのモデルに対応するデータ構造。

簡単なコードイメージ (UseCase と Repository):

// --- データアクセス層 (Data Layer) ---
// Repositoryプロトコル (インターフェース)
protocol UserRepository {
    func getUser(userId: String, completion: @escaping (Result<User, Error>) -> Void)
}

// Repository実装例
class UserRepositoryImpl: UserRepository {
    private let remoteDataSource: UserRemoteDataSource
    private let localDataSource: UserLocalDataSource

    init(remoteDataSource: UserRemoteDataSource, localDataSource: UserLocalDataSource) {
        self.remoteDataSource = remoteDataSource
        self.localDataSource = localDataSource
    }

    func getUser(userId: String, completion: @escaping (Result<User, Error>) -> Void) {
        // 例: まずローカルキャッシュを確認し、なければリモートから取得
        if let localUser = localDataSource.getUser(userId: userId) {
            completion(.success(localUser))
            return
        }

        remoteDataSource.fetchUser(userId: userId) { result in
            switch result {
            case .success(let remoteUser):
                self.localDataSource.saveUser(user: remoteUser) // ローカルにも保存
                completion(.success(remoteUser))
            case .failure(let error):
                completion(.failure(error))
            }
        }
    }
}

// --- ビジネスロジック層 (Domain Layer) ---
// UseCaseプロトコル
protocol GetUserUseCase {
    func execute(userId: String, completion: @escaping (Result<User, Error>) -> Void)
}

// UseCase実装例
class GetUserUseCaseImpl: GetUserUseCase {
    private let userRepository: UserRepository

    init(userRepository: UserRepository) {
        self.userRepository = userRepository
    }

    func execute(userId: String, completion: @escaping (Result<User, Error>) -> Void) {
        userRepository.getUser(userId: userId, completion: completion)
    }
}

// --- プレゼンテーション層 (Presentation Layer) ---
// ViewModel例 (SwiftUIを想定)
import Combine // Combineフレームワークを使用

class UserProfileViewModel: ObservableObject {
    @Published var userName: String = "Loading..."
    @Published var errorMessage: String? = nil

    private let getUserUseCase: GetUserUseCase
    private var cancellables = Set<AnyCancellable>() // Combine用

    init(getUserUseCase: GetUserUseCase) {
        self.getUserUseCase = getUserUseCase
    }

    func loadUser(userId: String) {
        self.userName = "Loading..."
        self.errorMessage = nil

        // 非同期処理の結果をハンドリング (Combineを使わない場合は単純なクロージャコールバック)
        // 実際には Result 型を Combine の Publisher に変換するなどが必要
        getUserUseCase.execute(userId: userId) { [weak self] result in
            DispatchQueue.main.async { // UI更新はメインスレッドで
                switch result {
                case .success(let user):
                    self?.userName = user.name
                case .failure(let error):
                    self?.userName = "Failed to load"
                    self?.errorMessage = error.localizedDescription
                }
            }
        }
    }
}

// (User, UserRemoteDataSource, UserLocalDataSource 構造体/クラスの定義は省略)
// (Combineを使った非同期処理の詳細は省略)

これらの例は非常に簡略化されていますが、各層がどのような責務を持ち、どのように連携するかの基本的なイメージを掴む助けになるはずです。重要なのは、プラットフォームやフレームワークの流儀に合わせつつも、「関心の分離」と「一方向の依存関係」というレイヤードアーキテクチャの原則を意識することです。

レイヤードアーキテクチャは、他の多くのアーキテクチャパターンと対立するものではなく、むしろそれらの基盤となったり、組み合わせて使われたりすることが多い概念です。

• MVC, MVP, MVVM: これらは主にプレゼンテーション層の内部構造をどのように設計するか、というパターンです。
  • MVC (Model-View-Controller): 古くからあるパターン。Model がデータとビジネスロジック、View が表示、Controller が両者の仲介役。モバイル開発では Controller が View と密結合しやすく、Fat Controller になりがち。
  • MVP (Model-View-Presenter): Controller の代わりに Presenter が View と Model を仲介。View と Presenter が1対1に近く、テストはしやすくなるが、定型コードが増える傾向。
  • MVVM (Model-View-ViewModel): View と ViewModel がデータバインディングで疎結合に連携。ViewModel が View の状態とロジックを持つ。Android Jetpack や SwiftUI と相性が良い。
  これらのパターンを採用する場合でも、その背後には通常、ビジネスロジック層（Modelの一部やUseCaseなど）やデータアクセス層（Modelの一部やRepositoryなど）が存在し、全体としてレイヤードアーキテクチャを構成しています。つまり、MVC/MVP/MVVM はレイヤードアーキテクチャのプレゼンテーション層をさらに詳細化したもの、と捉えることもできます。
• Clean Architecture: レイヤードアーキテクチャをより発展させ、依存関係のルールを厳格に定義したアーキテクチャです。Uncle Bob こと Robert C. Martin 氏によって提唱されました。
  • 中心に Entities (ドメインモデル) を置き、その周りに Use Cases (ビジネスロジック)、さらに外側に Interface Adapters (Presenter, Controller, Gatewayなど)、最も外側に Frameworks & Drivers (UI, DB, Web Frameworkなど) という同心円状の層で構成されます。
  • 最も重要なルールは「依存性のルール」で、依存関係は必ず外側から内側に向かう、というものです。つまり、内側の層は外側の層について何も知りません。
  • レイヤードアーキテクチャの「一方向の依存関係」と「依存性逆転の原則 (DIP)」を徹底した形と言えます。
  • モバイルアプリ開発でも、Clean Architecture の考え方を取り入れることで、よりテスト可能で保守性の高いアプリケーションを目指すことができますが、学習コストや実装コストは高くなる傾向があります。詳細はこちらの記事などが参考になります: The Clean Architecture
• MVI (Model-View-Intent): 状態管理とユーザー操作（Intent）の流れを単一方向（Unidirectional Data Flow）にすることで、予測可能でデバッグしやすいUIを実現するパターン。特に React や Jetpack Compose のような宣言的UIフレームワークと相性が良いです。これもプレゼンテーション層の実装パターンの一つであり、レイヤードアーキテクチャと組み合わせて使われます。

このように、レイヤードアーキテクチャは、様々な設計パターンを理解し、適用するための基礎となる考え方です。まずはレイヤードアーキテクチャの基本をしっかり押さえることが、より高度なアーキテクチャパターンを学ぶ上でも重要になります。

今回は、モバイルアプリ開発における基本的な設計手法である「レイヤードアーキテクチャ」について解説しました。

レイヤードアーキテクチャは、アプリケーションの機能を「プレゼンテーション層」「ビジネスロジック層」「データアクセス層」といった複数の層に分割し、それぞれの層が特定の責務を担うようにする設計です。このアーキテクチャの核心は「関心の分離」と「一方向の依存関係」にあります。

適切に適用することで、以下のような多くのメリットが期待できます。

• ✨ コードの可読性と保守性の向上
• ♻️ コンポーネントの再利用性の向上
• 🧪 テスト容易性の向上
• 🧩 変更に対する柔軟性と拡張性の向上
• 👥 チーム開発における分業の促進

一方で、小規模なアプリでは過剰になったり、コード量が増加したり、設計が難しかったりといった側面もあります。アプリケーションの特性に合わせて、適切な粒度で適用することが重要です。

レイヤードアーキテクチャは、MVC, MVP, MVVM, Clean Architecture といった他の多くのアーキテクチャパターンの基礎となる考え方でもあります。この基本を理解しておくことは、より複雑で洗練された設計を学ぶ上でも、必ず役に立つはずです。

モバイルアプリ開発において、動くものを作ることはもちろん大切ですが、将来の変化に対応し、長くメンテナンスしていくためには、しっかりとしたアーキテクチャ設計が不可欠です。ぜひ、今回学んだレイヤードアーキテクチャの考え方を、あなたのアプリ開発に取り入れてみてください！💡

次のステップとしては、MVVM や Clean Architecture など、より具体的なアーキテクチャパターンについて学んだり、依存性の注入 (Dependency Injection) といった関連技術について理解を深めたりすることをお勧めします。 Happy Coding! 😊