توضیح معماری شش ضلعی: چگونه توسعه نرم افزار خود را متحول کنید

Summarize this content to 400 words in Persian Lang

به طور کلی، درک می شود که نقش هر توسعه دهنده این است که “مشکلات را با استفاده از نرم افزار به عنوان یک ابزار حل کند”. این عبارت، اگرچه ساده است، اما از دو جنبه قابل درک است: پیچیدگی کسب و کار، شامل قوانینی برای حل مشکل. و پیچیدگی فنی، که فناوری ادغام شده در کسب و کار برای به کار انداختن آن است.

با این حال، اغلب، آنچه ما مشاهده می‌کنیم، برنامه‌هایی هستند که ذاتاً آنقدر ادغام شده‌اند که دیگر نمی‌توان تشخیص داد که چه چیزی پیچیدگی تجاری و چه چیزی پیچیدگی فنی است.

سناریوی زیر را در نظر بگیرید: استراتژی های بازاریابی شرکت. برای انجام این کار، آنها از SDK شرکت Y با روش ‘send_event’ استفاده می کنند که در هر نقطه از سیستم که یک رویداد در آن رخ می دهد، پیاده سازی می شود. دو ماه بعد، با افزایش هزینه ها برای استفاده از سیستم شرکت Y، شرکت X تصمیم می گیرد به شرکت Z مهاجرت کند. آیا جایگزینی SDK Y با Z در این مورد فرآیند ساده ای خواهد بود؟

به راحتی می توانیم نتیجه بگیریم که اینطور نیست. کد Y در سراسر سیستم جفت شد و پیچیدگی کسب و کار را “کثیف” کرد. جایگزینی استفاده از آن فرآیندی سخت و زمان بر خواهد بود.

معماری شش ضلعی که «پورت‌ها و آداپتورها» نیز نامیده می‌شود، دقیقاً برای جلوگیری از این اتفاق می‌آید. در امتداد این خطوط، ما می‌توانیم برخی از نکات مهم در مورد یک معماری خوب طراحی شده را مثال بزنیم:

رشد پایدار: نرم افزار باید مقیاس پذیر باشد و بتواند به روشی ساده بهبود یابد، به طوری که به مرور زمان هزینه سرمایه گذاری خود را بپردازد.
نرم افزار باید توسط ما طراحی شود و نه توسط چارچوب – ما باید جفت بین پیچیدگی فنی و تجاری را کاهش دهیم.
بدون زحمت زیاد قابل تعویض است

به عبارت دیگر، ما می توانیم معماری را به عنوان آینده نرم افزار درک کنیم.

با این حال، اغلب، چه به دلیل عدم دانش در مورد معماری، یا تغییرات پیچیده بازار، ما شاهد رشد نرم افزار به روشی بسیار ناپایدار هستیم. در زیر چرخه عمر بسیاری از پروژه های امروزی را مثال می زنم.

فاز 1:در این مرحله پروژه شروع می شود. پایگاه داده، ثبت نام ها، احراز هویت، سرور، نماها، کنترلرها و غیره پیاده سازی می شوند.

سطح 2:قوانین کسب و کار را به ثبت اضافه کنید، یک ACL برای مجوز پیاده سازی کنید، لاگ اضافه کنید، API ایجاد و مصرف کنید.

فاز 3:دسترسی بسیار افزایش می یابد، برنامه به صورت افقی مقیاس می شود (ارتقای سخت افزار)، ما شروع به کار با حافظه پنهان، مصرف API های شخص ثالث و اجرای قوانین تجاری شریک می کنیم.

فاز 4:دسترسی‌های بیشتر، ارتقاء بیشتر، درخواست‌های بانکی بیشتر که شروع به ایجاد گلوگاه می‌کنند، نسخه ۲ از API پیاده‌سازی می‌شود.

فاز 5:این نرم افزار به صورت عمودی مقیاس بندی شده است، در چندین ماشین بارگذاری می شود (ما کار را با S3 شروع کردیم)، بازسازی زیادی برای انجام مقیاس عمودی، ایجاد مقیاس خودکار، خط لوله CI/CD.

فاز 6:ما شروع به استفاده از graphQL برای برخی از APIها کردیم، اشکالات به دلیل تغییر فرمت ها، مشکلات مربوط به گزارش ها در بسیاری از ماشین ها شروع به ظاهر شدن کردند – شروع کردیم به فکر کردن در مورد سیستمی برای متمرکز کردن، ادغام با پلت فرم CRM ایجاد شد.

فاز 7:ما شروع به ناهماهنگی در داده‌های CRM کردیم، به فکر محفظه‌سازی برنامه‌مان بودیم – باید CI/CD، حافظه، گزارش‌ها را بازنگری کنیم و از شر کدهای قدیمی خلاص شویم.

فاز 8:ما شروع به کار با میکروسرویس ها می کنیم، شروع به اشتراک گذاری پایگاه های داده می کنیم، شروع به مشکلات ردیابی می کنیم، سرعت سیستم کاهش می یابد، هزینه ها بالا می رود.

فاز 9:ما دیگر نمی‌توانیم با کانتینرها کار کنیم و به Kubernetes می‌رویم، باید دوباره CI/CD را دوباره انجام دهیم، شروع به مشکلات انعطاف‌پذیری می‌کنیم، بدون داشتن تجربه زیادی شروع به کار با پیام‌رسانی می‌کنیم و شروع به از دست دادن پیام‌ها می‌کنیم. استخدام نرم افزار مشاوران برای کمک.

فاز 10:از تخیل استفاده کنید!

از تجزیه و تحلیل این مراحل، می توان دریافت که نرم افزار یک شبه از بین نمی رود، بلکه یک روز در یک زمان از بین می رود. این سیستم مانند یک میراث به نظر می رسد، با بدهی های فنی که هیچ کس نمی خواهد با آن مقابله کند.در زیر برخی از بازتاب‌های این چرخه زندگی ارائه شده را فهرست می‌کنم:

فقدان چشم‌اندازی برای آینده وجود داشت: ما نمی‌توانیم این فکر را داشته باشیم که نرم‌افزار همیشه ساده/کوچک خواهد بود. یک دقیقه او بزرگ می شود.
تعریف ضعیف محدودیت ها: هیچ تفکیک واضحی بین آنچه که یک کسب و کار است و آنچه یک چارچوب است وجود نداشت، ایجاد یک جفت و ایجاد مشکل برای تبادل و افزودن اجزا.
عدم آمادگی برای مقیاس بندی: در ابتدا همه چیز در همان سرور است – پول نقد، سیاهههای مربوط، آپلود. با این حال، وقتی شروع به مقیاس افقی و سپس عمودی می کنیم، باید بسیاری از کارها را دوباره انجام دهیم. بنابراین، ما باید از روز اول فکر کنیم و برای مقیاس آماده شویم.
فقدان محدودیت برای بهینه سازی های مکرر: نرم افزار همیشه به ویژگی های جدید با ضرب الاجل محدود نیاز خواهد داشت و در صورت عدم تعیین حد قابل قبول، شروع به ایجاد و حفظ بدهی فنی بیشتر و بیشتر خواهیم کرد.
قادر به مقابله با تغییرات ناگهانی نیستید: به عنوان مثال: شرکت دروازه پرداخت را تغییر داد یا پلت فرم CRM → آیا می توانیم به راحتی پیاده سازی را تغییر دهیم؟

می‌توانیم ببینیم که اگر از روز اول چشم‌اندازی از آینده داشته باشیم، می‌توانیم لایه‌های ضد فساد ایجاد کنیم تا تغییرات بر تجارت تأثیر نگذارد و کار ما را سخت‌تر نکند.

همچنین مهم است که تفاوت بین این دو مفهوم که اغلب یک چیز در نظر گرفته می شوند برجسته شود. در زیر تعریفی است که من آن را بسیار موجز و کامل می دانم که از مقاله زیر خلاصه شده است: https://eximia.co/quais-sao-as-diferencas-entre-arquitetura-e-design-de-software/

فعالیت‌های مرتبط با معماری نرم‌افزار همیشه طراحی هستند. با این حال، همه فعالیت های طراحی در مورد معماری نیستند. هدف اصلی معماری نرم افزار اطمینان از رعایت ویژگی های کیفیت، محدودیت های سطح بالا و اهداف تجاری توسط سیستم است. هر تصمیم طراحی که با این هدف مرتبط نباشد، معماری نیست. هر گونه تصمیم طراحی برای یک جزء که خارج از آن “مشاهده” نیست، معمولاً قابل مشاهده نیست.

به عبارت دیگر، می‌توانیم معماری را به‌عنوان چیزی که باعث می‌شود نرم‌افزاری با کیفیت، کارآمدی و تضمین کارکرد کسب‌وکار ارائه کنیم، چیزی انتزاعی‌تر درک کنیم. طراحی به این صورت است که ما می خواهیم این کار را انجام دهیم، چیزی ملموس تر.

بسیاری از تصمیمات طراحی هیچ ارتباطی با معماری ندارند، اما می توانند بر تصمیمات معماری نیز تأثیر بگذارند. در اینجا یک مثال است:

“همه سیستم ها باید لاگ ایجاد کنند و در یک مکان ذخیره شوند” – چشم انداز معماری

“برای اینکه این امکان را فراهم کنیم، مطمئن شویم که گزارش در یک فایل نوشته نشده است، بلکه از طریق ترمینال خروجی می شود” – چشم انداز طراحی

به گفته آلیستر کاکبرن، می‌توان معماری شش ضلعی را به صورت زیر تعریف کرد:

به یک برنامه اجازه دهید به طور یکسان توسط کاربران، برنامه‌ها، اسکریپت‌های آزمایشی یا دسته‌ای خودکار هدایت شود و جدا از دستگاه‌ها و پایگاه‌های داده در زمان اجرای نهایی آن توسعه و آزمایش شود.»

به طور خلاصه، اساساً با جداسازی روش دسترسی افراد و سیستم ها به آن و نحوه دسترسی آن به سایر سیستم ها، نرم افزار ایجاد می کند. از تصویر زیر می توانیم این مفهوم را بهتر درک کنیم:

با نگاهی به تصویر، قلب برنامه خود یعنی تجارت را در مرکز شش ضلعی داریم. برای برقراری ارتباط با اشیاء خارجی (هم کلاینت و هم سرور که توسط آداپتورهای مربوطه انتزاع می‌شوند)، رابط‌هایی (پورت‌ها) ایجاد کردیم تا از اتصال مستقیم برنامه من (کسب و کار) به آداپتور و بالعکس جلوگیری کنیم.

ذکر این نکته مهم است که شکل شش ضلعی فقط یک ساختار دلخواه برای نشان دادن است – می تواند هر شکل دیگری باشد. نکته این است که ما نمی خواهیم پیچیدگی کسب و کار را با پیچیدگی فنی مخلوط کنیم.

در این خط، ما توانستیم ادغام را با اشیاء خارجی مختلف مانند گزارش‌ها، حافظه پنهان، پایگاه‌داده، صف‌های پیام، کلاینت (REST، gRPC، GraphQL)، و افزودن و جایگزینی آن‌ها را از طریق «پورت‌ها» و «آداپتورها» تسهیل کنیم.

به روشی عملی تر، باید از یکی از مفاهیم SOLID استفاده کنیم – اصل وارونگی وابستگی – برای دستیابی به این وضوح:

ماژول های سطح بالا (اشیاء خارجی) به ماژول های سطح پایین (تجارت) وابسته نیستند، اما هر دو باید به انتزاع ها بستگی داشته باشند.
انتزاع ها نباید به جزئیات بستگی داشته باشند و بالعکس.

کاری که ما در اینجا انجام می دهیم، معکوس کردن کنترل است. به عنوان مثال، اگر من یک کلاس B را مستقیماً در کلاس A دیگر نمونه سازی کنم، یک جفت ایجاد می کنم. کاری که من می خواهم انجام دهم این است که آن را در داخل سازنده دریافت کنم. با این حال، برای جلوگیری از این جفت شدن بین دو کلاس، باید یک رابط در سازنده A دریافت کنم، که به طور غیر مستقیم B را نشان می دهد.

همه این مفاهیم به طور کامل روش توسعه نرم افزار با کیفیت را تغییر می دهند.

در نهایت، می‌توانیم این مفاهیم را که اغلب اشتباه می‌شوند، از هم متمایز کنیم. در معماری شش ضلعی هیچ استاندارد مشخصی برای نحوه سازماندهی کد وجود ندارد، بر خلاف Clean و Onion Architecture، از کدام لایه ها یا ساختارهای پوشه استفاده شود. این فقط اصل جدایی بین قلب برنامه و اشیاء خارجی را تعریف می کند.

در این محیط، تا زمانی که از قوانین سازمانی پیروی از ماهیت مفاهیمی که در این مقاله در مورد آن صحبت می‌کنیم، لزوماً نیازی به پیاده‌سازی ساختار شناخته‌شده (Clean/Oonion) نداریم. اما البته، اجرای ساختارهای قبلاً مطالعه شده و شناخته شده مطمئناً روند را بسیار آسان تر می کند.