Flutter Mobile Development · レッスン

ドメイン、データ、プレゼンテーション層の境界

厳格な依存関係ルールに従い、関心事をエンティティ、リポジトリ、ユースケースに分離します。

「ドメイン、データ、プレゼンテーション層の境界」はCoddyKit上の無料Flutter Mobile Developmentレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはFlutter Mobile Development学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Flutter Mobile Developmentコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Layer Boundaries Matter

In a Flutter app of any real size, mixing UI, business rules, and data access into the same files turns every change into a regression risk. Clean Architecture splits the app into three layers:

Domain — pure business rules: entities and use cases. No Flutter, no HTTP, no Dart packages tied to I/O.
Data — implements repositories: API clients, databases, DTO mapping.
Presentation — widgets, state management (Bloc/Riverpod), and view models.

The single most important rule: dependencies point inward. Presentation and Data depend on Domain. Domain depends on nothing.

The Dependency Rule

The Domain layer is the stable core. It must never import from Data or Presentation. Think of it as a circle: arrows of dependency only ever point toward the center.

Presentation -> Domain (allowed)
Data -> Domain (allowed)
Domain -> Data (forbidden)
Domain -> Presentation (forbidden)

Because Domain owns the repository interfaces (abstractions), the Data layer that implements them depends inward. This is the Dependency Inversion Principle in action.

Domain Entities

An entity is a plain Dart object that models a core business concept. It carries no JSON parsing, no fromMap, no framework annotations. Keep it immutable and free of I/O concerns.

Notice this class imports nothing from Flutter or any network library. It is pure Dart and could compile in a console app.

class User {
  final String id;
  final String name;
  final String email;

  const User({
    required this.id,
    required this.name,
    required this.email,
  });

  User copyWith({String? name, String? email}) => User(
        id: id,
        name: name ?? this.name,
        email: email ?? this.email,
      );
}

void main() {
  const user = User(id: '1', name: 'Ada', email: 'ada@example.com');
  final renamed = user.copyWith(name: 'Ada L.');
  print('${renamed.id}: ${renamed.name} <${renamed.email}>');
}

Repository Interfaces Live in Domain

The Domain layer declares what data operations exist, not how they happen. It does this with an abstract class (interface). The Data layer provides the concrete implementation later.

This abstraction is the seam that lets Domain stay ignorant of HTTP, SQLite, or Firebase. The return types use Domain entities only.

abstract class UserRepository {
  Future<User> getUser(String id);
  Future<void> saveUser(User user);
}

class User {
  final String id;
  final String name;
  final String email;
  const User({required this.id, required this.name, required this.email});
}

Use Cases Orchestrate Business Rules

A use case (also called an interactor) represents one unit of application behavior, such as "fetch the profile of the signed-in user." It depends only on repository interfaces from Domain.

Keeping each use case as a single-responsibility class makes the business intent explicit and trivially testable with a fake repository.

class GetUser {
  final UserRepository repository;
  const GetUser(this.repository);

  Future<User> call(String id) => repository.getUser(id);
}

abstract class UserRepository {
  Future<User> getUser(String id);
  Future<void> saveUser(User user);
}

class User {
  final String id;
  final String name;
  final String email;
  const User({required this.id, required this.name, required this.email});
}

Data Layer: DTOs and Models

The Data layer introduces models (DTOs) that know how to serialize. A common pattern is to extend or map from the Domain entity, keeping JSON logic out of Domain entirely.

Here UserModel handles fromJson/toJson and exposes a toEntity() conversion so the rest of the app only ever sees the pure User.

class UserModel {
  final String id;
  final String name;
  final String email;

  const UserModel({required this.id, required this.name, required this.email});

  factory UserModel.fromJson(Map<String, dynamic> json) => UserModel(
        id: json['id'] as String,
        name: json['name'] as String,
        email: json['email'] as String,
      );

  Map<String, dynamic> toJson() => {'id': id, 'name': name, 'email': email};

  User toEntity() => User(id: id, name: name, email: email);
}

class User {
  final String id;
  final String name;
  final String email;
  const User({required this.id, required this.name, required this.email});
}

void main() {
  final model = UserModel.fromJson({'id': '7', 'name': 'Grace', 'email': 'g@x.io'});
  final entity = model.toEntity();
  print('Entity name: ${entity.name}');
}

Data Layer: Repository Implementation

The concrete repository lives in Data and implements the Domain interface. It wires together remote data sources, local caches, and DTO mapping. Note the implements UserRepository clause — the dependency points inward to Domain.

It returns User entities, never UserModel, so serialization details never leak upward.

class UserRepositoryImpl implements UserRepository {
  final UserRemoteDataSource remote;
  const UserRepositoryImpl(this.remote);

  @override
  Future<User> getUser(String id) async {
    final model = await remote.fetchUser(id);
    return model.toEntity();
  }

  @override
  Future<void> saveUser(User user) {
    final model = UserModel(id: user.id, name: user.name, email: user.email);
    return remote.putUser(model);
  }
}

abstract class UserRemoteDataSource {
  Future<UserModel> fetchUser(String id);
  Future<void> putUser(UserModel model);
}

Presentation Depends Only on Use Cases

The Presentation layer (a Bloc, Cubit, or Riverpod notifier) holds references to use cases, not to repositories or data sources. This keeps widgets decoupled from how data is fetched.

Below, a Cubit calls the GetUser use case and emits view state. It knows nothing about JSON or HTTP.

class UserCubit extends Cubit<UserState> {
  final GetUser getUser;
  UserCubit(this.getUser) : super(UserInitial());

  Future<void> load(String id) async {
    emit(UserLoading());
    try {
      final user = await getUser(id);
      emit(UserLoaded(user));
    } catch (e) {
      emit(UserError(e.toString()));
    }
  }
}

Mapping the Folder Structure

A feature-first layout makes boundaries visible on disk. Each feature owns its three layers:

lib/features/user/domain/ — entities, repositories (interfaces), usecases
lib/features/user/data/ — models, datasources, repositories (impl)
lib/features/user/presentation/ — cubit/bloc, pages, widgets

When a file in domain/ imports from data/, you have a boundary violation. Lint rules (e.g. import_lint or custom analysis_options.yaml bans) can enforce this automatically.

Error Handling Across Boundaries

Low-level exceptions (a SocketException, a 404) belong to the Data layer. Don't let them bubble up raw into Domain or Presentation. Convert them into domain-level Failure types so the UI reasons about meaning, not transport.

A common idiom is returning Either<Failure, T> (via the dartz package) from repositories, or throwing typed domain exceptions caught at the use-case edge.

sealed class Failure {
  const Failure(this.message);
  final String message;
}

class NetworkFailure extends Failure {
  const NetworkFailure() : super('No connection');
}

class NotFoundFailure extends Failure {
  const NotFoundFailure() : super('Resource not found');
}

String describe(Failure f) => switch (f) {
      NetworkFailure() => 'Check your internet.',
      NotFoundFailure() => 'We could not find that.',
      _ => 'Something went wrong.',
    };

void main() {
  print(describe(const NetworkFailure()));
  print(describe(const NotFoundFailure()));
}

Testing Each Layer in Isolation

Strict boundaries pay off in tests. Because a use case depends on an interface, you can inject a fake repository with zero network or Flutter test harness.

This test runs in plain Dart — no WidgetTester, no mock HTTP server — proving the Domain layer is genuinely decoupled.

abstract class UserRepository {
  Future<User> getUser(String id);
}

class User {
  final String id;
  final String name;
  const User({required this.id, required this.name});
}

class GetUser {
  final UserRepository repo;
  const GetUser(this.repo);
  Future<User> call(String id) => repo.getUser(id);
}

class FakeUserRepository implements UserRepository {
  @override
  Future<User> getUser(String id) async => User(id: id, name: 'Test User');
}

void main() async {
  final useCase = GetUser(FakeUserRepository());
  final user = await useCase('42');
  print(user.id == '42' && user.name == 'Test User'
      ? 'PASS'
      : 'FAIL');
}

Checkpoint: The Dependency Direction

Consider a Flutter feature using Clean Architecture. Where should the UserRepository abstract interface be declared, and which layer implements it?

Recap

You separated a Flutter feature into three layers with strict, inward-pointing dependencies:

Domain — pure entities, repository interfaces, and use cases; depends on nothing.
Data — DTO models with JSON logic, data sources, and repository implementations that map models to entities.
Presentation — Blocs/Cubits that call use cases and never touch serialization or HTTP.

Key takeaways: declare repository interfaces in Domain (Dependency Inversion), convert transport errors into domain Failures at the boundary, keep entities free of framework imports, and enforce the rules with folder structure plus lint bans. The reward is a codebase where each layer is independently testable and changes stay local.

よくある質問

「ドメイン、データ、プレゼンテーション層の境界」レッスンは無料ですか？

はい。「ドメイン、データ、プレゼンテーション層の境界」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Flutter Mobile Developmentコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Flutter Mobile Developmentコースには全4レッスンが含まれています。

「ドメイン、データ、プレゼンテーション層の境界」で何を学びますか？

厳格な依存関係ルールに従い、関心事をエンティティ、リポジトリ、ユースケースに分離します。ブラウザで直接実行するハンズオンコードでFlutter Mobile Developmentを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Flutter Mobile Developmentを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFlutter Mobile Developmentは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「ドメイン、データ、プレゼンテーション層の境界」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFlutter Mobile Developmentレッスンでコードを書いて実行できますか？

はい。すべてのFlutter Mobile Developmentレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Flutter Mobile Developmentに戻る