আমার ফোল্ডারগুলি কি ব্যবসার ডোমেন বা প্রযুক্তিগত ডোমেন দ্বারা সংগঠিত করা উচিত?


19

উদাহরণস্বরূপ, আমি যদি কিছু এমভিসি-মতো আর্কিটেকচার ব্যবহার করি তবে আমার কোন ফোল্ডারের কাঠামোটি ব্যবহার করা উচিত:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

বা:

controllers/
    domain1
    domain2
models/
    domain1
    domain2
views/
    domain1
    domain2

আমি এই প্রশ্নটি ভাষা-অজ্ঞাবলিক রাখতে ইচ্ছাকৃতভাবে ফাইল এক্সটেনশানগুলি রেখেছি।

ব্যক্তিগতভাবে, আমি ব্যবসায় ডোমেন (অন্ত্র অনুভূতি) দ্বারা পৃথক করতে পছন্দ করব তবে আমি দেখতে পাচ্ছি যে বেশিরভাগ / অনেকগুলি ফ্রেমওয়ার্ক প্রযুক্তিগত ডোমেন দ্বারা পৃথক। কেন আমি একজনকে অন্যের থেকে পছন্দ করব?


2
ফ্রেমওয়ার্কগুলি ব্যবসায়িকদের নয়, বিকাশকারীদের লক্ষ্য করে। বিকাশকারীরা প্রযুক্তিগত ভিত্তিক দৃষ্টিভঙ্গি এবং ফ্রেমওয়ার্কগুলিকে বিবেচনায় নিয়ে আরও আরামদায়ক হওয়ার প্রত্যাশা করছেন - এটি আপনি যা পর্যবেক্ষণ করেছেন তার কারণ হতে পারে
gnat

উত্তর:


15

আমি মনে করি এটি নির্দিষ্ট প্রকল্পের উপর নির্ভর করে।

উদাহরণস্বরূপ, যদি বিভিন্ন ব্যবসায়িক ডোমেন একে অপরের থেকে সম্পূর্ণ স্বতন্ত্র থাকে তবে আমি ব্যবসায় ডোমেন দ্বারা সংগঠিত করব।

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

দু'জনের মধ্যে একটি (সোনালী) মাঝপথে রয়েছে - এর নিজস্ব ডোমেনের মধ্যে ভাগ করা কোডটি ফেলা এবং অন্য ডোমেনে এটি ব্যবহার করুন। এটি আপনাকে আপনার অন্ত্রে অনুভূতি চালিত বিন্যাস দেয়, তবে ব্যবসায়িক ডোমেনগুলির মধ্যে ভাগ করা কোডটিকে মঞ্জুরি দেয়।

Domain1              # This domain changes bits of standard MVC code
  controllers
  models
  views
Domain2              # this domain only modifies views, all else is standard
  views
Shared               # Here is the better part of code base
  controllers
  models
  views

পুনশ্চ. আমি মনে করি যে বেশিরভাগ ফ্রেমওয়ার্কগুলি প্রযুক্তিগত ডোমেন দ্বারা সংগঠিত হয় কারণ তারা আশা করে যে আপনি বিভিন্ন ব্যবসায়িক ডোমেনগুলি একক প্রকল্পের সাথে মিশ্রিত করেন তবেই যদি আপনার কোড ভাগ করা থাকে এবং অন্যথায় পৃথক প্রকল্প তৈরি করা হয়।

সম্পাদনা করুন:

উদাহরণস্বরূপ, ধরুন কোনও ওয়েব অ্যাপ রয়েছে যা কোনও সংস্থার গুদাম পরিচালনা করে। জেনেরিক আকারে এটি অনেক সংস্থার ক্ষেত্রে প্রযোজ্য হতে পারে তবে তাদের প্রত্যেকেরই কিছু নির্দিষ্ট বৈশিষ্ট্য থাকতে পারে যা পূরণ না করে এবং তাদের কিনতে নিষেধ করে Eg দুটি ডিফল্ট পরিবর্তে আইটেমটি তিন স্তরে সংগঠিত করতে।

আপনি অবশ্যই এই সংস্থার প্রত্যেকটির জন্য প্রকল্পটি কাঁটাচামচ করতে পারেন। তবে যদি কাঠামো / ভাষা মঞ্জুরি দেয় তবে আপনি প্রতিটি গ্রাহকের প্রয়োজন অনুসারে জেনেরিক প্রকল্পের বিট এবং টুকরোগুলি কাস্টমাইজ করতে এবং ব্যবসায় ডোমেন বিন্যাসে তাদের সংগঠিত করতে সাবক্লাসিং বা প্লাগইন ইত্যাদি ব্যবহার করতে পারেন।

উদাহরণস্বরূপ, যদি জেনেরিক প্রকল্পটি কেবল JSON এ কেবল আইটেমকে রপ্তানি করে তবে ডোমেন 1 নিয়ামককে সাবক্লাস করতে পারে এবং এটি সাম্প্রতিক সরবরাহের সমস্যাগুলিও রফতানি করতে পারে।

এবং আপনি যদি পরে দেখতে পান যে ডোমেন 1 এর এমন একটি উপাদান রয়েছে যা ডোমেন 2 এর জন্যও বৈধ, আপনি এর জেনেরিক সংস্করণটি ভাগ করে নিতে পারেন।

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


আমি ধারণাটি দুর্দান্ত, কিন্তু আমি ব্যবহারিক উদাহরণ কল্পনা করতে ব্যর্থ। আপনি কি একটি সহজ কিন্তু আলোকিত করতে পারেন?
ফ্লোরিয়ান মার্জাইন

@ ফ্লোরিয়ানমারগাইন - আমি আপনাকে একটি বাস্তব বিশ্বের উদাহরণ দেব। রিয়েল এস্টেট ওয়েবসাইট। আমার শেষ কাজটিতে আমরা অনেক গ্রাহকের কাছে বেশ কয়েকটি রিয়েল এস্টেট ওয়েবসাইট বিক্রি করেছি। সমস্ত 50+ গ্রাহকের জন্য আমাদের একটি কেন্দ্রীয় ডাটাবেস ছিল। প্রতিটি ব্যাক-এন্ড অ্যাডমিন মডিউলগুলির একটি ভাগ করে নেওয়া সেট ব্যবহার করে। প্রতিটি গ্রাহক মুখোমুখি অনন্য চিত্র এবং নেভিগেশন ব্যবহার করে। প্রতিটি অনুসন্ধান এবং ড্রিল ডাউন পৃষ্ঠাগুলি ভাগ করে নেওয়া মডিউলগুলি ব্যবহার করে যেখানে গ্রাহক এক-অফ বৈশিষ্ট্য চেয়েছিলেন wanted এই এক-অফের জন্য আমরা কোডটি আলাদা করে দিয়েছি এবং তাদের নিজস্ব মডিউল দিয়েছি। (খসড়া: আপগ্রেডগুলি সাধারণ মডিউলগুলিতে করতে হয়েছিল এবং ওয়ান-অফ মডিউলগুলিতে নকল করা হয়েছিল)
মাইকেল রিলে -

8

আমি মনে করি এটি জিজ্ঞাসা করা জ্ঞানজনক যে, "আমি নিয়মিত, আরও বেশি ডোমেন বা আরও প্রযুক্তিগত বিভাগে কী যুক্ত করতে পারি?" তারপরে উত্তর যাই হোক না কেন, এটিকে শীর্ষ স্তরে রাখুন।

বেশিরভাগ ক্ষেত্রে আপনার প্রযুক্তিগত আর্কিটেকচারটি আপনার ডোমেনের চেয়ে দ্রুত দৃify়তর হবে। এর অর্থ আপনার প্রথমে ডোমেন দ্বারা, তারপরে আর্কিটেকচারাল উপাদান দ্বারা সংগঠিত করা উচিত। কারণটি হ'ল যখন কোনও ডোমেনে কিছু পরিবর্তন হয় তখন আপনাকে সেই ডোমেনে একাধিক প্রযুক্তিগত উপাদান যুক্ত করতে বা পরিবর্তন করতে হতে পারে তবে আশা করা যায় এটি স্থানীয়ীকৃত এবং অন্য ডোমেনগুলিতে খুব বেশি ছড়িয়ে পড়ে না।

আপনি যদি আপনার জিইউআই কাঠামোটি পরিবর্তন করে থাকেন তবে তার অর্থ আপনার পরিবর্তনগুলি পুরো অ্যাপ্লিকেশন জুড়ে ছড়িয়ে পড়বে, তবে তারপরে আবার আপনি খুব কমই আপনার জিইউআই কাঠামো পরিবর্তন করেন তবে আপনি সর্বদা আপনার ডোমেন যুক্তি পরিবর্তন করছেন।

জিনিসগুলি একই সময়ে পরিবর্তিত হওয়ার সম্ভাবনা থাকলে একত্রে রাখুন।


সেরা পরামর্শ, তবে আমি কী ধরণের ডোমেনগুলি সর্বাধিক যুক্ত করতে চলেছি তা কীভাবে পূর্বাভাস দিতে হয় তা আমি দেখতে পাচ্ছি না।
ফ্লোরিয়ান মার্জাইন

শেষ বাক্য এটি নখ।
হাকান ডেরিয়াল

@ ফ্লোরিয়ানমারগেইন - আমি মনে করি না যে "ডোমেন" ডোমেইনের বিষয়টি গুরুত্বপূর্ণ। আপনি যদি নতুন প্রযুক্তিগত "জিনিস" যুক্ত করেন তার চেয়ে বেশি আপনি ডোমেন যুক্ত করেন তবে প্রথমে ডোমেন অনুসারে সমস্ত কিছুকে গ্রুপ করুন।
স্কট হুইটলক

3

আরও একটি বিকল্প রয়েছে এবং এটি প্লাগিনগুলিতে পৃথক অংশগুলি সরিয়ে নিয়েছে। কেকপিএইচপি উদাহরণস্বরূপ এটি করে। এটি আপনাকে পুনরায় ব্যবহারযোগ্য এমন সম্পূর্ণ এমভিসি অংশগুলি তৈরি করতে দেয় যা আপনি চান এমন কোনও যুক্তি অনুসারে বাছাই করতে পারেন।

আপনার মূল অ্যাপ্লিকেশনটি কেবল সেগুলি ব্যবহার করবে এবং তাদের সাথে লিঙ্ক করবে।

মূলত আপনার প্রশ্নটি সংহতি এবং মিলন সম্পর্কে। আপনি পৃথক অংশগুলি যথাসম্ভব স্বতন্ত্রভাবে কাজ করতে চান। এইভাবে আপনি পরীক্ষামূলক এবং পুনরায় ব্যবহারযোগ্য কোড পান।

এটি বিবেচনায় রেখে: আপনি যদি ডোমেন দ্বারা বিভক্ত হন তবে আপনি কীভাবে আপনার আবেদনের অংশগুলি পুনরায় ব্যবহার করবেন? উদাহরণস্বরূপ একটি ওয়েবশপ নিন: একটি আদেশ / অর্ডার / ভিউ / 1 এর জন্য আসে যাতে আপনাকে অর্ডার এনআর দেখাতে হবে। 1. / অর্ডার / নিয়ন্ত্রক / অর্ডার_কন্ট্রোলারে যায় আপনি যদি পণ্য এবং অর্ডার দ্বারা ডোমেন পৃথক করে থাকেন তবে আপনার ইতিমধ্যে অন্য "ডোমেন" এর কিছু অংশের প্রয়োজন হবে।

সেখানে আপনি জিনিসগুলিকে ইন্টারফেসিং শুরু করতে পারেন তবে সম্ভবত বেশিরভাগ ব্যবসায়ের ক্ষেত্রে খুব সংশ্লেষযোগ্য। আপনি যদি প্রযুক্তিগত পন্থা গ্রহণ। উদাহরণস্বরূপ আপনার কাছে একটি প্লাগইন হ্যান্ডলিং অর্ডার থাকতে পারে। আপনি আপনার কেন্দ্রীয় অ্যাপ্লিকেশন থেকে পণ্য অবজেক্টগুলিতে এটি রেখেছেন। এইভাবে আপনি প্লাগইনটি সহজেই পরীক্ষা করতে পারবেন, কেবল একটি নাম এবং দাম দিয়ে কিছু পণ্য অবজেক্ট তৈরি করুন এবং এতে প্রেরণ করুন।

প্লাগিনটি যা করতে হবে ঠিক তা করবে। এটি নির্ভর করবে এটির ইনপুটটির উপর এবং অন্যান্য "অংশ / ডোমেন / অঞ্চল" এর উপর নয়।


ভাল ধারণা. এটি আমার উত্তরের মূলত শীর্ষ-ডাউন। আমি ভাগ করে নেওয়া কোডটি শীর্ষে রেখেছি এবং মূলত ডোমেন স্পেসিফিকেশনে প্লাগ ইন করি। আপনি শীর্ষে ডোমেন রেখেছেন এবং ভাগ করা কোডটি প্লাগ করুন। আমি মনে করি উভয়ই ডি-কাপলিং এবং টেস্টিবিলিটি সম্পর্কে সমানভাবে ভাল পন্থা।
লাস

2

মাইক্রোসফ্ট এএসপি.নেট এমভিসি 3-তে "অঞ্চলগুলি" ধারণা রয়েছে। আপনি যখন আপনার এমভিসি প্রকল্পের মধ্যে "অঞ্চলগুলি" প্রবর্তন করেন, তারা এগুলি এড়িয়ে যায়:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

আমি এটি বেশ স্বাভাবিক বলে মনে করেছি। একটি অঞ্চল একটি প্রকল্পের "বৃহত্তর অংশ", এবং একটি স্ব-সংযুক্ত ইউনিটে কাজ করা সবেমাত্র উপলব্ধি করে।

আমরা ম্যাচের জন্য নেমস্পেসগুলি ব্যবহার করেছি, FWIW।


2
আপনার অবদানের জন্য আপনাকে ধন্যবাদ, তবে কীভাবে এটি আমার প্রশ্নের উত্তর দেয়? (উভয় সমাধানের তুলনা করা)
ফ্লোরিয়ান মার্জাইন

@ ফ্লোরিয়ানমারগেইন: আমি ব্যাখ্যা করছি যে মাইক্রোসফ্ট কীভাবে এটি করেছে, (সম্ভবত ত্রুটিযুক্ত) ধারণা নিয়ে যে তারা আরও বুদ্ধিমান পথ বেছে নেওয়ার জন্য ইঞ্জিনিয়ারিংয়ের প্রচুর প্রচেষ্টা চালিয়েছে। আশা করি এটি কিছু ইনপুট দেয়।
gahooa

ঠিক আছে, তবে এটিই আমার প্রশ্নে ব্যবসায়ের কেন্দ্রিক
উপায়টি

1

300 000 কোডের লাইন সমন্বিত একটি ওয়েব শপের সাথে আমার ব্যক্তিগত অভিজ্ঞতা থেকে, আমি সর্বদা ব্যবসায়ের ডোমেন দ্বারা সংগঠিত হতে যাব। এইভাবে, আপনি কেবলমাত্র একটি কার্যকরী অঞ্চলে কাজ করার সময় সমস্ত প্রাসঙ্গিক শ্রেণীর একটি দ্রুত ওভারভিউ পেতে পারেন না, জাভাতেও আপনি প্যাকেজটির দৃশ্যমানতার ব্যবহার করতে পারবেন।

যারা আগ্রহী তাদের জন্য কিছু বিশদ: প্রকল্পটি যখন 5 বছর আগে শুরু হয়েছিল, তখন বিকাশকারীরা নিম্নলিখিত প্যাকেজ কাঠামোটি তৈরি করেছিলেন:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

প্রতিটি শপ ফাংশন যেমন শপিং কার্ট, পণ্য অনুসন্ধান ইত্যাদি বিভিন্ন ক্রিয়া নিয়ে থাকে যার প্রত্যেকটির নিজস্ব ফর্ম শ্রেণি থাকে (এমভিসি কাঠামোর দ্বারা আবদ্ধ কাঠামো)। অ্যাকশন প্যাকেজে আমরা কী শেষ করেছি 200 টিরও বেশি ক্লাস, প্রত্যেকে তাদের সম্পর্কিত ফর্ম শ্রেণী থেকে সম্পূর্ণ পৃথক হয়ে গেছে। সবচেয়ে খারাপটি হ'ল ক্রিয়াগুলি খুব বেশি যুক্তি প্রয়োগ করে না, তবে ফাংশন-নির্দিষ্ট পরিষেবাগুলিকে কল করে যা অন্য একটি প্যাকেজে থাকে।

আমি দলটিকে প্রস্তাব দিয়েছি এবং বোঝাতে পারি যে আমাদের ব্যবসায়ের ডোমেন দ্বারা প্যাকেজগুলি সংগঠিত করা উচিত। যুক্তিটি সহজ: আপনি যদি সমস্ত ক্রিয়াকলাপের তালিকা দেখতে চান তবে আপনি কেবল কোনও শালীন আইডিইর ধরণের শ্রেণিবিন্যাসের দৃশ্যটি খুলতে পারেন। যাইহোক, IDE যা করতে পারে না তা হ'ল কোনও শ্রেণীর অন্তর্ভুক্ত ব্যবসায়িক ডোমেনটি নির্ধারণ করা। তদুপরি, এই পদ্ধতির সাহায্যে আপনাকে কেবলমাত্র সেই ক্লাসগুলি সর্বজনীন করার অনুমতি দেয় যা বাকী প্যাকেজের দৃশ্যমানতার উপরে রেখে বেশ কয়েকটি কার্যকারিতা দ্বারা প্রয়োজনীয়।


0

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

ব্যক্তিগতভাবে, আমি আমার Foo কন্ট্রোলার এবং ফু রেপোজিটরি রাখা বা নিয়ন্ত্রকের ফোল্ডার এবং রেপোজিটরির ফোল্ডারের মাঝে যতদূর একসাথে এগিয়ে যাওয়ার চেয়ে প্রায়শই একসাথে রাখা অনেক সহজ বলে মনে করি, প্রায়শই ফু এর চারপাশে বৈশিষ্ট্য যুক্ত করার সময় উভয় ক্ষেত্রেই কাজ করা প্রয়োজন। বৃহত্তর প্রকল্পগুলিতে এটি আরও বেশি গুরুত্বপূর্ণ কারণ প্রযুক্তিগত ফোল্ডারগুলির মধ্যে দূরত্ব দুর্দান্ত হতে পারে এবং বিকাশের সময় একটি লক্ষ্যমাত্রার অপচয় হতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.