Flutter Mobile Development · درس

بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم

نظّم الميزات في حزم مستقلة وأدرها باستخدام مستودع Melos متعدد الحزم

بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم درس مجاني في Flutter Mobile Development على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Flutter Mobile Development، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Flutter Mobile Development 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

Why Feature-First?

As a Flutter app grows, the classic layer-first structure (top-level screens/, widgets/, models/, services/) starts to hurt. To touch one feature you jump across five folders, and unrelated teams collide in the same files.

Feature-first flips this: the top level is organized by business capability (auth, cart, profile), and each feature owns its own layers internally.

High cohesion — everything for a feature lives together.
Low coupling — features depend on contracts, not each other's internals.
Scalability — a feature can later be extracted into its own package with almost no churn.

Anatomy of a Feature Folder

Inside lib/features/<feature>/ we mirror Clean Architecture's three layers. The domain layer is pure Dart with no Flutter or plugin imports, which is exactly what makes a feature easy to extract later.

A typical auth feature:

data/ — DTOs, data sources, repository implementations.
domain/ — entities, repository interfaces, use cases.
presentation/ — widgets, pages, state (BLoC/Riverpod).

lib/
├── core/                  // shared cross-cutting code
│   ├── error/
│   └── network/
└── features/
    └── auth/
        ├── data/
        │   ├── models/
        │   ├── datasources/
        │   └── repositories/
        ├── domain/
        │   ├── entities/
        │   ├── repositories/
        │   └── usecases/
        └── presentation/
            ├── bloc/
            ├── pages/
            └── widgets/

The Domain Layer Is Pure Dart

The key discipline that makes a feature portable: the domain layer imports nothing from Flutter or plugins. Entities are plain immutable Dart classes, and repository contracts are abstract interfaces.

Because this code has no framework dependencies, it is trivially unit-testable and can run on any Dart VM — including an online judge.

// domain/entities/user.dart
class User {
  final String id;
  final String email;
  const User({required this.id, required this.email});
}

// domain/repositories/auth_repository.dart
abstract class AuthRepository {
  Future<User> signIn(String email, String password);
}

void main() {
  const user = User(id: '1', email: 'ada@example.com');
  print('Loaded ${user.email}');
}

Use Cases Encode Business Rules

A use case is a single-responsibility object that orchestrates one application action. It depends only on the repository interface, never on its implementation. This keeps the presentation layer dumb and the rules testable.

The common Flutter convention is to give each use case a call method so it can be invoked like a function.

// domain/usecases/sign_in.dart
class User {
  final String email;
  const User(this.email);
}

abstract class AuthRepository {
  Future<User> signIn(String email, String password);
}

class SignIn {
  final AuthRepository repository;
  const SignIn(this.repository);

  Future<User> call(String email, String password) {
    if (!email.contains('@')) {
      throw ArgumentError('Invalid email');
    }
    return repository.signIn(email, password);
  }
}

class FakeRepo implements AuthRepository {
  @override
  Future<User> signIn(String email, String password) async => User(email);
}

void main() async {
  final signIn = SignIn(FakeRepo());
  final user = await signIn('ada@example.com', 'pw');
  print('Signed in: ${user.email}');
}

From Folders to Packages

Feature-first folders are a great first step, but folders don't enforce boundaries — any file can still import any other. The next level is to make each feature a real Dart package with its own pubspec.yaml.

Now the compiler enforces isolation: a package can only use what it explicitly declares as a dependency. This is where a monorepo comes in — many packages, one repository.

packages/feature_auth/
packages/feature_cart/
packages/core/
apps/mobile/ (the runnable Flutter app that wires features together)

What Is Melos?

Melos is a CLI tool for managing Dart/Flutter monorepos with multiple packages. It solves the pain of running pub get, tests, and version bumps across dozens of packages.

Bootstrap — links local packages together and resolves all dependencies in one command.
Scripting — define named scripts that run across every package.
Versioning — conventional-commit based version bumps and changelogs.

You install it once globally and configure it per repository with a melos.yaml.

dart pub global activate melos

# from the monorepo root
melos bootstrap   # or: melos bs

Configuring melos.yaml

At the repo root, melos.yaml declares the workspace name and where packages live (glob patterns). Modern Melos (3+) also supports declaring the workspace inside the root pubspec.yaml, but a dedicated file remains common.

The packages globs tell Melos which folders are managed members of the monorepo.

# melos.yaml
name: shop_workspace

packages:
  - apps/**
  - packages/**

command:
  bootstrap:
    usePubspecOverrides: true

Wiring Local Path Dependencies

Inside the app, you depend on local feature packages by name. With usePubspecOverrides: true, Melos injects the local path: overrides automatically during bootstrap, so your committed pubspec.yaml can reference versions while local development still uses source.

The result: editing a file in feature_auth is instantly visible to the app — no publishing, no copy-paste.

# apps/mobile/pubspec.yaml
name: mobile
dependencies:
  flutter:
    sdk: flutter
  feature_auth: ^1.0.0
  feature_cart: ^1.0.0
  core: ^1.0.0

# Melos generates pubspec_overrides.yaml on bootstrap:
# dependency_overrides:
#   feature_auth:
#     path: ../../packages/feature_auth

Defining Workspace Scripts

The biggest day-to-day win is scripts. You define a command once and run it across every package that matches a filter. This replaces brittle shell loops.

Common filters include --dir-exists=test (only packages that have tests) and --depends-on=core (only packages depending on a given package).

# melos.yaml
scripts:
  analyze:
    run: melos exec -- dart analyze .
    description: Analyze every package.

  test:
    run: melos exec --dir-exists=test -- flutter test
    description: Run tests only where a test/ dir exists.

# usage:
#   melos run analyze
#   melos run test

Keeping Features Decoupled

Packages enforce boundaries, but you still must design the contracts. The rule of thumb:

Features never import each other directly.
Shared contracts and primitives live in a low-level core package that everything may depend on.
Cross-feature navigation goes through an abstraction (a router or an event bus) injected at the app level.

This dependency direction — features → core, app → features — keeps the graph acyclic. A cycle between two feature packages will fail to resolve, which is a useful early warning.

// packages/core/lib/src/app_route.dart  (shared contract)
abstract class AppRouter {
  void goToCart();
  void goToProfile();
}

// feature_auth depends on `core`, never on feature_cart.
class LoginController {
  final AppRouter router;
  const LoginController(this.router);

  void onLoginSuccess() => router.goToCart();
}

void main() => print('Auth depends on core, not on cart.');

A Typical Developer Workflow

Putting it together, the daily loop in a Melos monorepo is short and uniform regardless of how many packages you have:

melos bootstrap after pulling new changes to relink packages.
melos run analyze and melos run test in CI and locally.
melos version to bump changed packages from conventional commits.

Because the app is the only Flutter-runnable target and features are plain packages, your CI can test domain logic on the pure Dart VM (fast) and only spin up Flutter for presentation tests.

# clone + first run
melos bootstrap
melos run analyze
melos run test

# ship a release
melos version          # bumps + changelogs from commits
cd apps/mobile && flutter build apk

Quick Check

You have a Melos monorepo with feature_auth and feature_cart packages. After login, auth needs to navigate the user to the cart screen. What is the cleanest way to keep the dependency graph acyclic?

Recap

You learned how to scale a Flutter codebase from folders to packages:

Feature-first structure groups code by business capability, each feature mirroring data/domain/presentation layers.
The domain layer stays pure Dart, making it portable and easy to extract.
Promoting features to Dart packages lets the compiler enforce boundaries that folders cannot.
Melos manages the resulting monorepo: bootstrap links packages, scripts run commands across all of them, and version automates releases.
Keep the graph acyclic: features depend on core, the app depends on features, and cross-feature concerns go through shared contracts.

الأسئلة الشائعة

هل درس «بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم» مجاني؟

نعم — نص درس «بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Flutter Mobile Development، انتقل إلى CoddyKit PRO. تتضمن دورة Flutter Mobile Development 4 دروس في المجموع.

ماذا ستتعلم في «بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم»؟

نظّم الميزات في حزم مستقلة وأدرها باستخدام مستودع Melos متعدد الحزم تتمرن على Flutter Mobile Development مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Flutter Mobile Development؟

لا تُشترط خبرة سابقة. Flutter Mobile Development على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.

كم من الوقت يستغرق درس «بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Flutter Mobile Development هذا؟

نعم. كل درس في Flutter Mobile Development يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

حدود طبقات المجال والبيانات والعرض
حقن الاعتماديات باستخدام get_it وinjectable
بنية المجلدات التي تبدأ بالميزات ومستودعات Melos متعددة الحزم
Either وأنواع الفشل ومعالجة الأخطاء الوظيفية

← العودة إلى Flutter Mobile Development