Flutterアプリケーション構築における「関心の分離」と「アーキテクチャ」

開発言語

技術解説

連載 [第4回] :

Flutterで実現する“効率的”モバイル開発

2025年7月22日(火)

加納愼之典

第4回の今回は、Flutterアプリケーションにおける関心の分離とレイヤードアーキテクチャについて解説します。</p>

はじめに

これまでの連載では、Flutterの基本概念から始まり、状態管理、そしてUI構築まで、アプリケーション開発に必要な基本的な要素を解説してきました。第4回となる今回は、これらの要素を統合した設計について深く掘り下げていきます。

小規模なアプリケーションであれば、これまで学んだ知識だけでも十分に開発を進めることができます。しかし、アプリケーションが成長し、機能が増え、開発チームが拡大するにつれて、コードの保守性と拡張性が重要な課題となってきます。適切なアーキテクチャの設計は、この課題に対する根本的な解決策となります。

何より「関心の分離(Separation of Concerns)」は、ソフトウェア設計における最も重要な原則の1つです。それぞれのコードが単一の責任を持ち、他の部分から独立して変更できるようにすることで、コードの理解しやすさと保守性が大幅に向上します。

本稿では、Flutterアプリケーション開発で採用される様々なアーキテクチャパターンの中でも、特に「レイヤードアーキテクチャ」に焦点を当て、なぜこのパターンが多くの開発現場で選ばれているのか、そして実際にどのように実装していくのかを、具体的なコード例とともに解説していきます。

なぜFlutterアプリケーションにアーキテクチャが必要なのか
関心の分離の具体的な実践方法
レイヤードアーキテクチャの各層の役割と実装
テスタビリティの向上とその重要性
実際のプロジェクトでの適用例

特に、Webフロントエンド開発やネイティブアプリ開発の経験がある方にとっては、それぞれの環境でのアーキテクチャパターンとFlutterでのアプローチの違いを理解する良い機会となるでしょう。

それでは、より保守性が高く、拡張可能なFlutterアプリケーションを構築するための設計思想を探っていきましょう。

なぜアーキテクチャが必要なのか

「動けば良い」という考え方は、プロトタイプや小規模なアプリケーションでは通用するかもしれません。しかし、実際の開発においてコードは常に変化し続けます。新機能の追加、バグの修正、パフォーマンスの改善など、様々な理由でコードに手を加える必要が生じます。

技術的負債の蓄積

アーキテクチャを考慮せずに開発を進めた場合、いくつかの深刻な問題に直面することになります。

変更の波及効果：一箇所の変更が予期せぬ場所に影響を与える
テストの困難さ：UIとビジネスロジックが密結合しているため、単体テストが書けない
コードの重複：同じような処理があちこちに散在する
理解の困難さ：新しいメンバーがコードベースを理解するのに時間がかかる

これらの問題は技術的負債として蓄積され、開発速度の低下と品質の劣化を招きます。

Flutterにおける特有の課題

Flutterの「Everything is a Widget」という設計思想は、UIの構築を直感的にする一方で、すべてをWidgetに詰め込んでしまう危険性もはらんでいます。

// アンチパターン：すべてをWidgetに詰め込んだ例
class ProductListScreen extends StatefulWidget {
  @override
  _ProductListScreenState createState() => _ProductListScreenState();
}

class _ProductListScreenState extends State&gl;ProductListScreen> {
  List<Product> products = [];
  bool isLoading = false;
  
  @override
  void initState() {
    super.initState();
    // API呼び出しロジックが直接Widgetに記述されている
    _loadProducts();
  }
  
  Future<void> _loadProducts() async {
    setState(() => isLoading = true);
    
    // HTTPリクエスト、エラーハンドリング、データ変換がすべて混在
    try {
      final response = await http.get(Uri.parse('https://api.example.com/products'));
      final data = json.decode(response.body);
      setState(() {
        products = data.map<Product>((json) => Product.fromJson(json)).toList();
        isLoading = false;
      });
    } catch (e) {
      // エラー処理
    }
  }
  
  @override
  Widget build(BuildContext context) {
    // UIの構築
    return Scaffold(
      // ...
    );
  }
}

このコードは動作しますが、いくつかの問題を抱えています。UIコンポーネントがデータ取得の詳細を知っていること、ビジネスロジックがUIレイヤーに混在していること、この画面のテストを書くためにはHTTPリクエストのモックが必要になること、そして他の画面で同じAPIを使いたい場合にコードの重複が発生することです。

レイヤードアーキテクチャとは

これらの問題を解決するため、本稿では「レイヤードアーキテクチャ」を採用します。

レイヤードアーキテクチャは、アプリケーションを明確な責任を持つ複数の層に分割するパターンです。一般的には、プレゼンテーション層、ドメイン層(ビジネスロジック層)、データアクセス層の3層構造を採用します。各層は隣接する層とのみ通信し、層を超えた直接的な依存関係を持ちません。

なぜレイヤードアーキテクチャなのか

Flutterアプリケーション開発には様々なアーキテクチャパターンが存在しますが、レイヤードアーキテクチャには以下の利点があります。

第1に理解しやすさです。レイヤードアーキテクチャは、アプリケーションを明確な層に分割するシンプルな概念です。各層の役割が明確で、初学者でも全体像を把握しやすいという特徴があります。

第2に段階的な適用が可能な点です。最初は簡単な2層構造から始めて、アプリケーションの成長に応じて層を追加していくことができます。これにより、過度な設計を避けながら、必要に応じて構造を洗練させていけます。

第3にFlutterのエコシステムとの親和性が高いことです。特に、Flutterコミュニティで広く採用されている「Riverpod」を使うことで、MVVM風の状態管理を効率的に実装できます。

関心の分離の原則

「関心の分離」とは、プログラムを明確に定義された責任を持つ部分に分割することです。各部分は特定の「関心事」に集中し、他の部分の詳細を知る必要がありません。

主要な関心事の種類

Flutterアプリケーションにおける関心事は、大きく4つに分類できます。

プレゼンテーション(UI)：ユーザーに情報を表示し、入力を受け取る
ビジネスロジック：アプリケーションの中核となる処理やルール
データアクセス：外部データソース(API、データベース)との通信
状態管理：アプリケーションの状態の保持と更新

これらの関心事を適切に分離することで、それぞれを独立して開発、テスト、保守できるようになります。

依存関係の方向

関心の分離において重要なのは、依存関係の方向です。上位レイヤー(UI)は下位レイヤー(ビジネスロジック)に依存しますが、下位レイヤーは上位レイヤーの存在を知りません。

// 良い例：UIがビジネスロジックに依存
class ProductListScreen extends StatelessWidget {
  final ProductRepository repository; // 依存性の注入
  
  const ProductListScreen({required this.repository});
  
  @override
  Widget build(BuildContext context) {
    // UIはrepositoryのメソッドを呼ぶだけ
    return FutureBuilder<List<Product>>(
      future: repository.getProducts(),
      builder: (context, snapshot) {
        // UI構築のロジックのみ
      },
    );
  }
}

レイヤードアーキテクチャの3層

プレゼンテーション層

「プレゼンテーション層」は、ユーザーインターフェースとユーザーとの対話を担当します。Flutterでは、WidgetとそれらのStateがこの層に属します。

// プレゼンテーション層：Widgetの実装(Riverpod使用)
// 商品リストの状態を管理するProvider
final productListProvider = FutureProvider<List<Product>>((ref) async {
  final repository = ref.watch(productRepositoryProvider);
  return repository.getProducts();
});

// UIの実装
class ProductListPage extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final productsAsync = ref.watch(productListProvider);
    
    return Scaffold(
      appBar: AppBar(title: const Text('商品一覧')),
      body: productsAsync.when(
        loading: () => const Center(child: CircularProgressIndicator()),
        error: (error, _) => Center(child: Text('エラー: $error')),
        data: (products) => ListView.builder(
          itemCount: products.length,
          itemBuilder: (context, index) {
            final product = products[index];
            return ProductListItem(product: product);
          },
        ),
      ),
    );
  }
}

プレゼンテーション層は、UIの構築と表示を担当します。ユーザーからの入力を受け取り、適切なビジネスロジックを呼び出します。また、アプリケーションの状態に応じて表示を切り替え、画面間のナビゲーションも制御します。

ドメイン層(ビジネスロジック層)

「ドメイン層」は、アプリケーションの中核となるビジネスロジックを含みます。この層は、UIの詳細やデータソースの実装から独立しています。

// ドメイン層：ビジネスロジックの実装
class Product {
  final String id;
  final String name;
  final double price;
  final int stock;
  
  Product({
    required this.id,
    required this.name,
    required this.price,
    required this.stock,
  });
  
  // ビジネスルール：在庫があるかどうか
  bool get isAvailable => stock > 0;
  
  // ビジネスルール：割引価格の計算
  double calculateDiscountPrice(double discountRate) {
    if (discountRate < 0 || discountRate > 1) {
      throw ArgumentError('割引率は0から1の間である必要があります');
    }
    return price * (1 - discountRate);
  }
}

// ユースケースの定義
abstract class ProductRepository {
  Future<List<Product>> getProducts();
  Future<Product> getProductById(String id);
  Future<void> updateStock(String productId, int newStock);
}

// ビジネスロジックを含むユースケース
class PurchaseProductUseCase {
  final ProductRepository repository;
  final PaymentService paymentService;
  
  PurchaseProductUseCase({
    required this.repository,
    required this.paymentService,
  });
  
  Future<PurchaseResult> execute(String productId, int quantity) async {
    // 商品情報を取得
    final product = await repository.getProductById(productId);
    
    // ビジネスルール：在庫確認
    if (product.stock < quantity) {
      return PurchaseResult.failure('在庫が不足しています');
    }
    
    // 支払い処理
    final amount = product.price * quantity;
    final paymentResult = await paymentService.processPayment(amount);
    
    if (paymentResult.isSuccess) {
      // 在庫を更新
      await repository.updateStock(productId, product.stock - quantity);
      return PurchaseResult.success();
    } else {
      return PurchaseResult.failure('支払いに失敗しました');
    }
  }
}

ドメイン層は、アプリケーションのビジネスルールを実装する場所です。ここではエンティティを定義し、ユースケースとして具体的なビジネス上の処理を実装します。また、ドメイン固有の例外も定義し、ビジネスルールに違反した場合の処理を明確にします。

データアクセス層

「データアクセス層」は、外部データソースとの通信を担当します。APIクライアント、データベースアクセス、キャッシュなどがこの層に含まれます。

// データ層：Repository実装
class ProductRepositoryImpl implements ProductRepository {
  final ApiClient apiClient;
  final LocalDatabase localDatabase;
  
  ProductRepositoryImpl({
    required this.apiClient,
    required this.localDatabase,
  });
  
  @override
  Future<List<Product>> getProducts() async {
    try {
      // APIから取得
      final response = await apiClient.get('/products');
      final products = (response.data as List)
          .map((json) => ProductDto.fromJson(json))
          .map((dto) => dto.toDomain())
          .toList();
      
      return products;
    } catch (e) {
      throw DataException('商品データの取得に失敗しました', e);
    }
  }
  
  @override
  Future<Product> getProductById(String id) async {
    // 実装...
  }
  
  @override
  Future<void> updateStock(String productId, int newStock) async {
    // 実装...
  }
}

// データ転送オブジェクト(DTO)
class ProductDto {
  final String id;
  final String name;
  final double price;
  final int stock;
  
  ProductDto({
    required this.id,
    required this.name,
    required this.price,
    required this.stock,
  });
  
  factory ProductDto.fromJson(Map<String, dynamic> json) {
    return ProductDto(
      id: json['id'],
      name: json['name'],
      price: json['price'].toDouble(),
      stock: json['stock'],
    );
  }
  
  Product toDomain() {
    return Product(
      id: id,
      name: name,
      price: price,
      stock: stock,
    );
  }
}

データアクセス層は、外部データソースとの橋渡しを担当します。外部APIとの通信、データベースへのアクセス、キャッシュの管理などがこの層の役割です。また、外部システムのデータ形式(DTO: Data Transfer Object)とドメインモデルの相互変換も行い、ドメイン層が外部システムの詳細を知らなくて済むようにします。

実践的な実装例

ここまでの理論を、実際のコードで実装してみましょう。商品検索機能を例に、レイヤードアーキテクチャを適用した実装を見ていきます。

プロジェクト構造

プロジェクトのディレクトリ構造も合わせて見ておきましょう。以下は、レイヤードアーキテクチャで採用される一般的な例です。

lib/
├── main.dart
├── core/
│   ├── errors/
│   │   └── exceptions.dart
│   └── utils/
│       └── constants.dart
├── features/
│   └── product/
│       ├── domain/
│       │   ├── entities/
│       │   │   └── product.dart
│       │   ├── repositories/
│       │   │   └── product_repository.dart
│       │   └── usecases/
│       │       └── search_products.dart
│       ├── data/
│       │   ├── datasources/
│       │   │   ├── product_remote_datasource.dart
│       │   │   └── product_local_datasource.dart
│       │   ├── models/
│       │   │   └── product_model.dart
│       │   └── repositories/
│       │       └── product_repository_impl.dart
│       └── presentation/
│           ├── bloc/
│           │   ├── product_search_bloc.dart
│           │   ├── product_search_event.dart
│           │   └── product_search_state.dart
│           └── pages/
│               └── product_search_page.dart

依存性注入とは

「依存性注入(Dependency Injection)」という言葉は難しく聞こえるかもしれませんが、概念はシンプルです。これは、あるクラスが必要とする他のクラス(依存関係)を、外部から「注入」する設計パターンです。

スマートフォンの充電器を例に考えてみましょう。スマートフォン(利用する側)は「充電する」という機能が必要ですが、その具体的な方法(USB-C、Lightning、ワイヤレス充電など)は気にしません。重要なのは「充電できる」という振る舞い(インターフェース)だけです。

// インターフェース(抽象クラス)の定義
abstract class ProductRepository {
  Future<List<Product>> getProducts();
  Future<Product> getProductById(String id);
}

// 実装クラス1：API経由でデータを取得
class ProductRepositoryImpl implements ProductRepository {
  final ApiClient apiClient;
  
  ProductRepositoryImpl({required this.apiClient});
  
  @override
  Future<List<Product>> getProducts() async {
    // APIから商品リストを取得
    final response = await apiClient.get('/products');
    return response.map((json) => Product.fromJson(json)).toList();
  }
}

// 実装クラス2：テスト用のモック実装
class MockProductRepository implements ProductRepository {
  @override
  Future<List<Product>> getProducts() async {
    // テスト用の固定データを返す
    return [
      Product(id: '1', name: 'テスト商品', price: 1000, stock: 5),
    ];
  }
}

// 利用する側のクラス
class ProductListNotifier {
  final ProductRepository repository; // インターフェースに依存
  
  // コンストラクタで依存性を注入
  ProductListNotifier({required this.repository});
  
  Future<void> loadProducts() async {
    // repositoryが実際にどの実装クラスなのかは知らない
    final products = await repository.getProducts();
    // ...
  }
}

このように、ProductListNotifierは具体的な実装(ProductRepositoryImplやMockProductRepository)ではなく、インターフェース(ProductRepository)に依存しています。これにより、本番環境では実際のAPI実装を、テスト環境ではモック実装を注入できます。

GetItとは

「GetIt」はFlutterで広く使われている依存性注入のためのサービスロケーターライブラリです。シンプルなAPIで、アプリケーション全体の依存関係を管理できるのでおすすめです。

GetItを使った依存性注入の実装を見てみましょう。

// dependencies/service_locator.dart
import 'package:get_it/get_it.dart';

final getIt = GetIt.instance;

void setupDependencies() {
  // 外部サービスの登録
  getIt.registerLazySingleton(() => http.Client());
  getIt.registerLazySingleton(() => LocalDatabase());
  
  // データソースの登録
  getIt.registerLazySingleton<ProductRemoteDataSource>(
    () => ProductRemoteDataSourceImpl(client: getIt()),
  );
  getIt.registerLazySingleton<ProductLocalDataSource>(
    () => ProductLocalDataSourceImpl(database: getIt()),
  );
  
  // リポジトリの登録
  getIt.registerLazySingleton<ProductRepository>(
    () => ProductRepositoryImpl(
      remoteDataSource: getIt(),
      localDataSource: getIt(),
    ),
  );
  
  // ユースケースの登録
  getIt.registerLazySingleton(
    () => SearchProductsUseCase(repository: getIt()),
  );
  
  // 状態管理クラスの登録(Factoryパターン)
  getIt.registerFactory(
    () => ProductListNotifier(repository: getIt()),
  );
}

// main.dart
void main() {
  setupDependencies();
  runApp(MyApp());
}

GetItでは、registerLazySingletonでシングルトンとして登録したり、registerFactoryで毎回新しいインスタンスを作成したりできます。getIt()を呼び出すだけで、登録された依存関係を取得できます。

このアプローチの利点は明確です。各クラスは自分の依存関係を直接作成する必要がなく、必要なものを外部から受け取るだけです。これにより、テスト時にモックオブジェクトを簡単に注入でき、各層を独立してテストできるようになります。

テスタビリティの向上

レイヤードアーキテクチャの大きな利点の1つは、テストが書きやすくなることです。各層が独立しているため、モックを使用して特定の層だけをテストできます。

ドメイン層のテスト

ビジネスロジックは外部依存がないため、純粋な単体テストが書けます。

// test/domain/entities/product_test.dart
void main() {
  group('Product', () {
    test('在庫がある場合、isAvailableはtrueを返す', () {
      final product = Product(
        id: '1',
        name: 'テスト商品',
        price: 1000,
        stock: 5,
      );
      
      expect(product.isAvailable, true);
    });
    
    test('在庫が0の場合、isAvailableはfalseを返す', () {
      final product = Product(
        id: '1',
        name: 'テスト商品',
        price: 1000,
        stock: 0,
      );
      
      expect(product.isAvailable, false);
    });
    
    test('割引価格が正しく計算される', () {
      final product = Product(
        id: '1',
        name: 'テスト商品',
        price: 1000,
        stock: 5,
      );
      
      expect(product.calculateDiscountPrice(0.2), 800);
    });
  });
}

おわりに

第4回となる今回は、Flutterアプリケーションにおける関心の分離とレイヤードアーキテクチャについて解説しました。

レイヤードアーキテクチャを使用することで、Flutterの特性を活かしながら保守性と拡張性の高いアプリケーションを構築できます。重要なのは、プロジェクトの規模に応じて適切なレベルの設計を選択することです。

皆さんのFlutterアプリケーション開発が、より効率的で楽しいものになることを願っています。

著者

加納愼之典

この著者の記事一覧この著者の
記事一覧

株式会社Fivot「IDARE」事業部エンジニア

神戸市外国語大学卒業後、江戸時代より約300年続く老舗和菓子屋に入社。伊勢本店勤務を経て東京路面店出店事業に従事したのち退職。餅、餡、モバイルアプリの製造を強みとし、現在はFlutterを用いた開発を中心に担当。札幌在住、二児の父。
個人向け貯蓄アプリであるイデアは「貯まるキャッシュレス」というコンセプトのもと、「高還元ボーナス」「充実の貯蓄サポート機能」「使いやすいプリカ」という3つの軸でサービスを展開しています。2021年4月のサービス開始から3年でユーザーが設定している目標金額の総額は150億円を突破。多くのユーザーに支持され、事業を拡大しています。
公式サイト: https://idare.jp/

連載バックナンバー

開発言語技術解説

第4回