ডোমেন চালিত ডিজাইনে রিফ্যাক্টরিং [বন্ধ]


10

আমি সবেমাত্র একটি প্রকল্পে কাজ শুরু করেছি এবং আমরা ডোমেন-চালিত ডিজাইন ব্যবহার করছি ( ডোমেন-ড্রাইভড ডিজাইনে এরিক ইভান্স দ্বারা নির্ধারিত হিসাবে : সফ্টওয়্যার হার্টে জটিলতা মোকাবেলা করা । আমি বিশ্বাস করি যে আমাদের প্রকল্পটি অবশ্যই এই ডিজাইনের প্রার্থী) প্যাটার্ন হিসাবে ইভান্স তার বইতে এটি বর্ণনা করে।

আমি ক্রমাগত রিফ্যাক্টরিংয়ের ধারণার সাথে লড়াই করছি।

আমি জানি যে কোনও প্রকল্পে রিফ্যাক্টরিং একটি প্রয়োজনীয়তা এবং সফ্টওয়্যার পরিবর্তনের সাথে সাথে এটি অনিবার্যভাবে ঘটবে। যাইহোক, আমার অভিজ্ঞতায়, রিফ্যাক্টরিং তখন ঘটে যখন ডেভেলপমেন্ট টিমের প্রয়োজনীয়তা পরিবর্তিত হয়, ডোমেন পরিবর্তনের হিসাবে বোঝা যায় না ("রিভ্যাক্টরিং অব বৃহত্তর অন্তর্দৃষ্টি" যেমন ইভান্স বলে। আমি ডোমেন মডেলটি বোঝার ক্ষেত্রে ব্রেকথ্রুগুলির সাথে সবচেয়ে বেশি উদ্বিগ্ন । আমি ছোট ছোট পরিবর্তনগুলি বুঝতে পেরেছি, তবে যদি মডেলটিতে একটি বৃহত পরিবর্তন প্রয়োজন হয়?

নিজেকে ক্লিয়ারার ডোমেন মডেল পাওয়ার পরে নিজেকে (এবং অন্যদের) বোঝানোর কার্যকর উপায় কী? সর্বোপরি, কোড সংগঠন বা কার্যকারিতা উন্নত করতে রিফ্যাক্টরিং সর্বব্যাপী ভাষার কোডের ক্ষেত্রে কতটা ভাববাদী তা থেকে সম্পূর্ণ আলাদা হতে পারে। কখনও কখনও মনে হয় রিফ্যাক্টরের পর্যাপ্ত সময় নেই।

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

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

ধন্যবাদ!


আপনি যদি এমন কোড লিখছেন যা আপনি ভাবেন না যে আপনি আকারের নির্বিশেষে কখনও পরিবর্তন করতে সক্ষম হবেন, থামুন।
জেফো

@ জেফ: এটি পরিবর্তন করতে না পারার বিষয়টি নয়, কোড যুক্ত হওয়ার সাথে সাথে এটি পরিবর্তনের জন্য প্রয়োজনীয় সময় এবং সংস্থানগুলির বিষয়।
অ্যান্ড্রু হুইটেকার

2
যদি আপনি বিদ্যমান কোডটি রিফ্যাক্টরিং জেনে কোড যুক্ত করে থাকেন এবং আপনি না করেন তবে আপনি একটি ঝুঁকি নিচ্ছেন। তার মানে এই নয় যে এটি কাজ করবে না।
জেফও

উত্তর:


9

আমি কিছুক্ষণের জন্য ডিডিডি-র একটি বড় অনুরাগী হয়েছি (পরীক্ষার কাঠামোর সুরক্ষা জাল সহ এবং তার বাইরে)।

রিফ্যাক্টরিংয়ের পুরো ধারণা এবং জীবনচক্র পরিবর্তন হয় না কারণ আপনি এখন একটি নতুন ডিজাইনের পদ্ধতি ব্যবহার করছেন। যদি এটি উল্লেখযোগ্য সময় নেয় তবে প্রকল্প থেকে সময়টি পাওয়ার জন্য এটির আনুপাতিক সুবিধা থাকতে হবে।

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


শুনে শুনে আপনি খুব খুশি হয়েছিলেন যে আপনি এত বড় রিফ্যাক্টর তৈরি করতে সফল হয়েছেন। এটি শুনতে আপনারা এতো ভাল যে আপনাকে শুরু করতে এত বড় পরিবর্তন করতে হয়েছিল। এটি আমি যে ধরনের রিফ্যাক্টরটির কথা বলছি। মাস বিশাল দীর্ঘ প্রভাব সহ।
অ্যান্ড্রু হুইটেকার

বৈশিষ্ট্য হিসাবে রিফ্যাক্টরিং একটি মনে রাখবেন।
ফিলিপ দুপানোভিć

5

ডোমেন ড্রাইভড ডিজাইনে রিফ্যাক্টরিং হ'ল আমি মনে করি কোনও "সুন্দর" রিফ্যাক্টর নয়, প্রয়োজন থেকে চালিত। আপনি কোনও ভুল ডোমেন মডেল সনাক্ত করার সাথে সাথে কোড / সিস্টেমটি আসল বিশ্বের সমস্যার প্রতিনিধিত্ব করছে না।

ঘটনাচক্রে, আমরা সম্প্রতি যুক্তিসঙ্গত ডোমেন জটিলতার একটি প্রয়োগে কাজ করেছি worked এটি একটি বিলিং / চুক্তি সিস্টেম ছিল এবং আমরা নতুন ধরণের হার প্রবর্তন করছিলাম। সুনির্দিষ্ট হওয়ার জন্য আমরা একটি চতুর প্রক্রিয়া ব্যবহার করছিলাম, 2 সপ্তাহের স্ক্রাম।

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

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

আমরা যখন প্রকল্পটি শেষ করেছি তখন আমরা বুঝতে পারিনি যে এটি করা সঠিক কাজ ছিল এবং এটি সঠিক করার জন্য কেবলমাত্র কাজ করা হয়েছিল।

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


দুর্দান্ত উত্তর। আমরা প্রতি কয়েক মাস পরে এর অনুরূপ কিছু দিয়ে যাব। আমরা একা নই এটা জেনে খুশি!
অ্যান্ড্রু হুইটেকার

3

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

এর ফলস্বরূপ এটি কী ঘটেছিল যে লোকেরা এমনভাবে মডেল তৈরি করত যা এটির জন্য উদ্ভাবিত ছিল না এবং এভাবে "এটি কাজ করার জন্য" চেষ্টা করার জন্য মডেলের অন্যান্য অংশগুলি ভেঙে দেয়।

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


3

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

প্রশ্নটি হল: "এই বিবর্তনগুলির কি দরকার হবে?" কোর ডোমেনে (যে ক্ষেত্রটি ব্যবসায়ের পার্থক্য করছে) উত্তরটি হ্যাঁ "হ্যাঁ!"! কারণ এটি সেই ডোমেনের প্রবণতাটি ব্যবসায়টি সম্পর্কে বেশি উদ্বিগ্ন এবং এটি স্টেকহোল্ডারদের জন্য একটি পার্থক্য আনবে। এটিই সেই জায়গা যেখানে আপনি নিজের কোডটি নিখুঁত আকারে রাখতে চান, আপনার ডোমেন মডেলটির নমনীয়তার কারণে ন্যূনতম প্রচেষ্টা সহ পরবর্তী প্রয়োজনীয়তা বাস্তবায়নের জন্য প্রস্তুত।

যাইহোক যে সমস্ত অ্যাপ্লিকেশন কোড প্রয়োগ করা ব্যয়বহুল হতে চলেছে । যে ক্ষেত্রগুলি ব্যবসায়ের পক্ষে তাত্পর্যপূর্ণ নয় ( ডিডিডি লিংগোতে সমর্থনকারী বা জেনেরিক সাবডোমাইনস ) মূলের জন্য সংরক্ষিত চেয়ে কম পরিশীলিত পদ্ধতির প্রয়োজন হতে পারে।

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