ساختار Folder per feature MVVM

نرم افزار ها نقش حیاتی برای یک کسب و کار رو دارن و یک اپلیکشن بد میتونه آینده یک کسب و کار رو تحت تاثیر قرار بده و برعکس این موضوع هم صادقِ هرچه نرم افزار توسعه پذیر تر باشه و هزینه نگهداری کمتری داشته باشه احتمال موفقیت اون کسب و کار بیشتر میشه!یکی از چالش هایی که در اکثر تیم های برنامه نویسی وجود داره که تیم فرانت اند تومن هم از این قاعده مستثنی نیست اسکیل کردن پروژه با حداقل هزینه هست. به همین دلیل چندتا از معماری های نرم افزار مرسوم بازار رو بررسی کردم و با توجه به چالش ها و نیاز های آینده پروژه تصمیم گرفتیم معماری که در ادامه توضیح میدم رو پیاده کنیم.چند نمونه از چالش های پیش روامکان اسکیل کردن پروژه (به صورت ماژولار یا مایکرو فرانت اند)امکان نوشتن تست برای پروژهقابلیت نوشتن چند UI مختلفقابلیت استفاده مجدد از کامپوننت هایادگیری ساده برای اعضای جدید تیمامکان داکیومنت کردن پروژهو....از اونجایی که تا الان هیچوقت دوست نداشتم چرخ رو از اول اختراع کنم تصمیم گرفتم معماری نرم افزار های مرسوم رو بیشتر مطالعه کنم تا تصمیم گیری برام راحت تر باشه برای معماری نرم افزار مقالات زیادی وجود داره و هر کدوم مزایا و معایب خودشون رو دارن. برای مثال معماری های زیر رو بررسی کردممعماری Cleanمعماری پیازیمعماری MVCمعماری MVVMو همچنین معماری های فولدر استراکچر زیر رو بررسی کردممعماری Group by file typesمعماری Group by Featuresو در نهایت تصمیم گرفتم معماری فولدر های مختلف رو با استفاده از مزیت های ذکر شده در معماری های بالا و شبیه به معماری Group by Features پیاده سازی و متناسب به نیاز های پروژه شخصی سازیش کنم folder per feature mvvmپوشه Assets:در این پوشه تمامی فایل های مورد نیاز توسعه مانند فایل های SVG تصاویر آیکون ها فونت ها و... قرار میگیرد.پوشه API:یکی از چالش هایی که ممکنه داشته باشیم بحث ارتباط با سرور هستش و ممکنه یکسری از دیتا هایی که از سمت سرور برگردانده میشود به هر دلیلی نیاز به بررسی مجدد و تغییر یا تبدیل داشته باشن. در این فولدر طبق استاندارد RESTful API برای هر اند پوینت یک CRUD در نظر میگیریم.پوشه Utility:− پوشه Helpers:در پوشه Helpers میتوان تابع هایی که در طول زمان توسعه نرم افزار چندین بار مورد استفاده قرار میگیرند را قرار داد− پوشه Hooks:در این پوشه میتوان کاستوم هوک هایی نوشت که در توسعه برنامه چندین بار مورد استفاده قرار گیرند− پوشه Consts:همانطور که از نام این پوشه مشخص است میتوان یک یا چندین فایل مختلف در این پوشه برای نگهداری ثابت های پروژه استفاده کرد مثلا میتوان تمامی متن های استفاده شده در برنامه و... را در این پوشه قرار دادپوشه Components:در این فولدر سه بخش مختلف داریم که در ادامه بررسی میکنیم- پوشه UIKit:در این پوشه تمامی کامپوننت های جزئی ولی پر تکرار پروژه قرار داده می شود برای مثال ما در پروژه ۵ نوع دکمه مختلف داریم که کاربرد های تقریبا مشابه دارند ولی دیزاین های متفاوتی دارند و برای همین یک کامپوننت به اسم Button در این پوشه ایجاد میکنیم.- پوشه Shared: بصورت پیشفرض این پوشه خالی میباشد و در تیم این قرارداد را رعایت میکنیم که هر سکشنی از صفحات باید به صورت Local components در نظر گرفته بشه ولی هر کامپوننتی در دیزاین که بیشتر از یکبار استفاده بشه باید به این پوشه انتقال پیدا کنه.پوشه Pagesدر این پوشه به ازای هر صفحه یک پوشه جدید ساخته میشود برای مثال ما در این پروژه دو صفحه به عنوان صفحه اصلی و لیست معاملات رو داریم که به ازای هر کدام یک پوشه جدید ایجاد شده است. در قدم بعدی باید هر کدام از این صفحات را بر اساس فیچر های مختلف کوچک میکنیم و در صورت نیاز مجدد همین روند رو تکرار میکنیم تا به کامپوننت هایی با قابلیت استفاده مجدد و معنا دار تقسیم بشن.کامپوننت هایی که در این صفحه به قسمت های کوچک تبدیل میشن به عنوان Local components در نظر گرفته میشن و در صورتی که در چندین جای پروژه استفاده بشن به Components/Shared انتقال پیدا میکنن.پیاده سازیبرای نمونه میخوام دیزاین زیر که مربوط به صفحه جزییات معامله میباشد رو طبق این معماری تقسیم بندی کنیم.صفحه جزییات معاملهمرحله اول: باید به ازای این صفحه یک پوشه جدید به اسم DealDetails در پوشه Pages ایجاد کنیمجدا سازی هدر و فوترمرحله دوم: قسمت هایی مثل هدر و فوتر صفحه که با صفحات دیگر مشترک است باید در پوشه Components/Shared پیاده سازی شودfolder per feature componentsمرحله سوم: در این مرحله باید هر قسمت صفحه به کامپوننت های معنادار تقسیم شود.ابتدا یک پوشه کامپوننت محلی برای جزییات معامله در نظر میگیریم. سپس این کامپوننت را به سه قسمت وضعیت معامله، جزییات و موارد معامله (رنگ آبی) تقسیم میکنیماین روند را برای تک تک این کامپوننت ها نیز مجدد اجرا میکنیم و کامپوننت وضعیت معامله نیز به دو قسمت قیمت و تایم لاین (رنگ قرمز) شکسته میشودکامپوننت تایم لاین نیز از تکرار کامپوننت وضعیت ساخته شده که این کامپوننت بر اساس وضعیت های مختلف آیکون، رنگ، عنوان، تاریخ و توضیحات آن متغیر است در نهایت باید خروجی فولدر ها مشابه تصویر زیر باشدfolder per feature MVVMدر تصویر بالا بعد از این که هر بخش رو به کامپوننت های کوچکتر تقسیم کردیم به ازای هر کامپوننت باید چند فایل ساخته شود که در ادامه در مورد هر کدام توضیح میدمفایل item.js:در این فایل فقط لایه view کامپوننت پیاده سازی میشه و قسمت منطق کامپوننت نباید در این لایه قرار بگیره و هر قسمتی که نیاز به لاجیک داشتیم باید از کاستوم هوک هایی و توابعی که در useItem.js پیاده شده استفاده کنیمفایل useItem.js:در این فایل باید تمامی منطق های کامپوننت پیاده سازی بشه همچنین تمام استیت ها در این فایل قرار میگیره و تمامی این تابع ها میتوانند توسط items.js استفاده شوندفایل item.style.js:در صورتی که برای استایل دهی فایل ها از styled-components یا ابزار های مشابه استفاده کنیم بهتر است استایل ها را جدا کرده و در این فایل قرار دهیمفایل item.test.js:در صورتی که برای پروژه تست بنویسیم تست ها در این فایل قرار می گیردچند نمونه از مزیت های جداسازی منطق و رابط کاربریمنطق برنامه به تنهایی قابل تست میباشدمیتوان با یک منطق چندین UI متفاوت پیاده سازی کرد (مثلا دو نسخه متفاوت برای موبایل و وب توسعه داد)میتوان به راحتی لایه view پروژه را ریدیزاین کردیادگیری و تسلط نیرو جدید با این استراکچر بیشتر استسخن پایانیاستفاده از این استراکچر یا هر معماری دیگه ای در هر پروژه ای ضروری نیست و تا حدود زیادی به عواملی همچون سایز پروژه و ظرفیت تیم و نوع دیزاین بستگی دارد.این معماری بیشتر در پروژه هایی که پیش بینی میشود نیاز به اسکیل شدن پیدا میکنند پیشنهاد میشود و در پروژه های کوچک باعث ایجاد پیچیدگی بی دلیل میشود