এনটিটি (Entities): আপনার অ্যাপের হার্ট বা প্রাণকেন্দ্র | পার্ট ২

Clean Architecture Entities: আপনার অ্যাপের হার্ট বা প্রাণকেন্দ্র

সফটওয়্যার ইঞ্জিনিয়ারিংয়ে আমরা প্রায়ই একটা ভুল করি—আমরা মনে করি ডেটাবেসের টেবিল বা API থেকে আসা ডেটাই বুঝি আমাদের অ্যাপের সবকিছু। কিন্তু আঙ্কেল ববের ক্লিন আর্কিটেকচার আমাদের শিখিয়েছে, ডাটাবেস বা API হলো ‘External Details’, এগুলো আপনার অ্যাপের মূল লজিক নয়।

আপনার অ্যাপের একদম মাঝখানে বা কেন্দ্রে থাকে Entity (এনটিটি)। একে বলা হয় ‘Enterprise Business Rules’।

এনটিটি আসলে কী?

সহজ কথায়, এনটিটি হলো এমন একটি অবজেক্ট বা ক্লাস যা আপনার বিজনেসের মূল নিয়মগুলো ধারণ করে। আপনার অ্যাপ যদি ফ্লাটার থেকে সরিয়ে কালকে নেটিভ অ্যান্ড্রয়েড বা আইওএস-এ নিয়ে যান, তবে আপনার ডেটাবেস বদলাতে পারে, কিন্তু এনটিটি বদলাবে না।

সবচাইতে বড় কনফিউশন: Model বনাম Entity

ডেভেলপার হিসেবে আমরা সবচেয়ে বেশি যেখানে ভুল করি তা হলো Model এবং Entity-কে এক করে ফেলা। চলুন বিষয়টি একটু ক্লিয়ার করি।

• Model: এটি ডাটা লেয়ারের অংশ। এটি জানে কীভাবে JSON থেকে ডেটা আনতে হয় (fromJson) বা ডাটাবেসে সেভ করতে হয়। এটি আপনার অ্যাপের বাইরের জগতের সাথে কথা বলে।
• Entity: এটি একদম ‘ক্লিন’ ডার্ট ক্লাস। এতে কোনো থার্ড পার্টি লাইব্রেরি বা JSON ম্যাপিং থাকবে না। এটি শুধু ডেটা এবং বিজনেস রুলস ধারণ করবে।

প্র্যাকটিক্যাল কোড ইমপ্লিমেন্টেশন

আমরা প্রায়ই ইউজারের ডেটা হ্যান্ডেল করি। চলুন দেখি ক্লিন আর্কিটেকচারে এটি কেমন হওয়া উচিত।

ধাপ ১: ক্লিন এনটিটি (The Clean Entity)

লক্ষ্য করুন, এখানে কোনো fromJson বা toJson নেই। এটি একদম স্বাধীন।

// Entity: Domain Layer-এ থাকবে
class UserEntity {
  final int id;
  final String fullName;
  final String email;

  UserEntity({
    required this.id, 
    required this.fullName, 
    required this.email,
  });
}

ধাপ ২: ডাটা মডেল (The Data Model)

মডেলটি এনটিটি-কে এক্সটেন্ড করবে এবং এখানে আমরা JSON হ্যান্ডেল করবো।

// Model: Data Layer-এ থাকবে
class UserModel extends UserEntity {
  UserModel({
    required super.id,
    required super.fullName,
    required super.email,
  });

  // JSON থেকে মডেল তৈরি করার লজিক শুধু এখানেই থাকবে
  factory UserModel.fromJson(Map<String, dynamic> json) {
    return UserModel(
      id: json['user_id'], 
      // খেয়াল করুন, API-তে নাম user_id থাকলেও অ্যাপে আমরা id ব্যবহার করছি
      fullName: json['first_name'] + " " + json['last_name'],
      email: json['email'],
    );
  }
}

কেন আমরা এই বাড়তি কষ্টটুকু করবো?

আপনি হয়তো ভাবতে পারেন, শুধু UserModel ব্যবহার করলেই তো কাজ চলতো। এই আর্কিটেকচার ফলো করার সুবিধা হলো:

1. ডিকাপলিং (Decoupling): কাল যদি আপনার ব্যাকএন্ড ডেভেলপার API-এর ফিল্ডের নাম first_name বদলে f_name করে দেয়, আপনাকে পুরো অ্যাপের কোথাও হাত দিতে হবে না। শুধু UserModel-এর fromJson মেথডটুকু চেঞ্জ করলেই হবে।
2. ক্লিন বিজনেস লজিক: আপনার ইউজ কেস বা ইউআই (UI) জানবে না যে ডাটা কোথা থেকে আসছে। তারা শুধু ‘Entity’ নিয়ে কাজ করবে।
3. টেস্ট্যাবিলিটি: কোনো ডাটাবেস বা নেটওয়ার্ক কানেকশন ছাড়াই আপনি আপনার এনটিটি এবং বিজনেস লজিক টেস্ট করতে পারবেন।

সারকথা

এনটিটি হলো আপনার অ্যাপের সেই ভিত যার ওপর পুরো বিল্ডিং দাঁড়িয়ে থাকে। একে সবসময় ফ্রেমওয়ার্ক এবং বাইরের দুনিয়া থেকে মুক্ত রাখা একজন প্রফেশনাল সফটওয়্যার ইঞ্জিনিয়ারের প্রধান দায়িত্ব।

পরবর্তী পর্বে আমরা দেখবো কীভাবে এই এনটিটিগুলোকে ব্যবহার করে আমরা Use Cases লিখবো এবং আমাদের অ্যাপের আসল লজিক কন্ট্রোল করবো।

এই সিরিজের প্রথম পর্বে আমরা ক্লিন আর্কিটেকচারের গুরুত্ব নিয়ে আলোচনা করেছি।

ক্লিন আর্কিটেকচার সম্পর্কে আরও গভীরে জানতে Uncle Bob-এর অরিজিনাল ব্লগ পড়তে পারেন।