සොෆ්ට්වෙයා සංවර්ධනයේ පළමු පියවර HLD (High Level Design) එකේ "කට්ටලයක්" හඳුන්වයි. එය පසුපස කුමක් තියෙනවද කියලා නොකියයි. මේ ලිපියෙන් අපි Low‑Level Design (LLD) මගින් Wishlist Service එකක් කෙලින්ම කුමක් කරන්නේ, එහි ෆංක්ෂන්වල සැලසුම, දෝෂ සැලැස්වීම, සහ ව්යාපාරික නීති කොහෙද යන දේ පියවරෙන් පියවර හඳුන්වමු.
Uncle සහ Nephew අතර කතාබහේදී, Uncle එකම කට්ටලයක් (Wishlist Service) ගැන පූර්ණයෙන්ම හඳුනා ගන්න කියලා කියයි. "ඇඩ් එකක්, රිමූව් එකක්, ලිස්ට් එකක්" කියලා පේළි පමණක් නොව, ඒ ෆංක්ෂන්වල ඇතුළත් පරාමිතීන්, ආපසු දෙන අගය, සහ දෝෂයන් කෙලින්ම නිරූපණය කරගත යුතුය.
උදාහරණයක් ලෙස addItem(userId, productId) ෆංක්ෂන් එකේ ප්රවේශය, පළමුව validateInput කරයි, පසුව checkDuplicate කරයි, අවසානව save කරයි. Duplicate‑check එක වෙනම ෆංක්ෂන් ලෙස නිර්මාණය කිරීමේ ප්රයෝජනය, අනාගතයේ Bulk Import වැනි නව විශේෂතා එකතු කිරීමේදී කේතය නැවත භාවිතා කිරීම සරළ කරයි. කේත පිටපත් කිරීමෙන් ඇතිවන බග්ග් එකක් හෝ අලුත්ම ව්යාපාරික නීතියක් වෙනස් කිරීමේදී මේවා වෙන්ව තිබීමෙන් වැඩි ආරක්ෂාව ලැබේ.
දෝෂ සැලැස්වීමේදී, "return {success:false}" වැනි ප්රතිඵලයක් වෙනුවට throw ProductNotFoundError සහ DuplicateItemError වැනි නාමික දෝෂයන් භාවිතා කිරීමේ හේතුව, කැලැක්රමකාරී ලෙස පරීක්ෂා නොකිරීමේ අවදානම අඩු කිරීමයි. API ස්ථරයට 404, 409 වැනි HTTP status code ගත කිරීම සදහා මේ නාමික දෝෂයන් ඉතා වැදගත්.
ශ්රී ලංකාවට ඇති වැදගත්කම
- ඉගෙනුම් පියවර: LLD සැලසුම සිංහලෙන් පැහැදිලිව අධ්යයනය කළොත්, අපේ විශ්වවිද්යාල සිසුන්ට සැලසුම් සිද්ධාන්තය ප්රායෝගිකව ගැඹුරු කරගන්න හැකියාව ලැබේ.
- විකසකයන්ට ප්රයෝජනය: නිවැරදි ෆංක්ෂන් සැලසුම කේත ලියන කාලය කෙටි කරයි, බග් අඩු කරයි, සහ පද්ධතියේ scalability වැඩි කරයි.
- ව්යාපාරික ප්රතිලාභ: හොඳ LLD නිසා නවතම විශේෂතා ඉක්මනින් එකතු කරගැනීමට, සේවා නාමික දෝෂ කළමනාකරණය හරහා API එකේ response ගුණාත්මක කරගැනීමට හැකියාව ලැබේ.
Low‑Level Design එකේ පූර්ණ අවධානයෙන් සැලසුම් කරනවා නම්, පසුපස කේත ලියීමේදී අඩු දෝෂ, ඉහල maintainability, සහ වේගවත් feature rollout එකක් අපේ රටේ තාක්ෂණික වර්ධනයට නව අභිලාෂයක් වේ.
එබැවින්, ඔබේ ඊළඟ Wishlist සේවාව හෝ වෙනත් microservice එකක් නිර්මාණය කරන විට, LLD අඩංගු විස්තරාත්මක සැලසුමක් සකස් කර, කේත ලියන පියවරට පෙර සියලුම නීති, පරාමිතීන්, සහ දෝෂ ප්රතිචාර තීරණය කරගන්න.
