فصل 15 کتاب Clean Architecture : معماری چیست؟

کتاب معماری تمیز

واژه ی معماری، تصور قدرت و معماآميز بودن را به ذهن می آورد. معماری ما را وادار می کند به تصمیمات مهم و مهارت فنی عمیق فکر کنیم. معماری نرم افزار در اوج موفقیت فنی است. وقتی به معمار نرم افزار فکر می کنیم، به شخص قدرتمند و قابل احترام فکر میکنیم. کدام جوان مشتاق توسعه دهنده ی نرم افزار آرزو نکرده است که روزی یک معمار نرم افزار شود؟

اما معماری نرم افزار چیست؟ معمار نرم افزار چه کاری می کند و چه زمانی کارش را انجام می دهد؟ اول از همه یک معمار نرم افزار، یک برنامه نویس است و همچنان به کار برنامه نویسی خود ادامه می دهد. هرگز در این اشتباه نیافتید که معماران نرم افزار برای تمرکز در سطح بالا، از برنامه نویسی کناره گیری می کنند.

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

معماری یک سیستم نرم افزاری، شکل دادن به آن سیستم، توسط کسانی است که آن را ساخته اند. فرم دادن به آن شکل در تقسیم آن سیستم به کامپوننتها، ترتیب آن کامپوننتها و راههایی که در آن کامپوننت ها با یکدیگر ارتباط برقرار میکنند، است.

هدف از آن شکل، تسهیل در توسعه، استقرار، بهره برداری و نگهداری سیستم نرم افزاری موجود در آن است.

 

استراتژی که پشت این راه گشایی است تا آنجا که امکان دارد گزینه های بسیاری در اختیار ما قرار میدهد.

 

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

مشکلات آنها در عملکردشان پنهان نیست بلکه در استقرار، نگهداری و توسعه ی مداوم اتفاق میافتد. نمیتوان گفت که معماری در رفتار مناسب سیستم نقشی ایفا نمیکند. قطعاً نقش دارد و این نقش حیاتی است. اما این نقش، منفعل و سطحى است، فعال یا ضروری نیست. گزینه های رفتاری (Behavioral options) که معماری سیستم بتواند باز باشد کم است.

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

 

توسعه

توسعه یک سیستم نرم افزاری که دشوار باشد، به احتمال زیاد عمر طولانی و سالمی نخواهد داشت. بنابراین معماری یک سیستم، باید توسعه را برای تیمهایی که این نقش را به عهده دارند، راحت کند. ساختار گروهی مختلف به تصمیمات معماری متفاوتی دلالت دارد. از یک طرف یک تیم کوچک از پنج توسعه دهنده میتواند کاملاً مؤثر با یکدیگر کار کنند تا یک سیستم یکپارچه را بدون کامپوننت های معلوم یا اینترفیس ها توسعه دهد. در حقیقت چنین تیمی به احتمال زیاد استراتژیهای یک معماری را تا اندازه ای که در طول روزهای اولیه مانع از یکپارچگی سیستم است، پیدا خواهد کرد. به احتمال زیاد دلیل آن این است که بسیاری از سیستمها معماری خوبی ندارند: آنها با هیچ یک از استراتژیهای معماری آغاز نشده اند چرا که تیم کوچک بوده و نمی خواسته مانع از فراساختاری (Superstructure) شود.

 

استقرار

برای مؤثر بودن، سیستمهای نرم افزاری باید قابل تحویل باشند. هزینه استقرار بالاتر، سودمندی سیستم را کمتر میکند. پس از آن، هدف یک معماری نرم افزار، ایجاد یک سیستم است که میتواند به راحتی با یک کار واحد توسعه یابد.

متأسفانه استراتژی استقرار در زمان توسعه اولیه (Initial development) به ندرت مورد بررسی قرار میگیرد. این کار منجر به سیستمی میشود که میتواند سیستم را به آسانی توسعه دهد، اما استقرار آن بسیار دشوار است. به عنوان مثال، در ابتدای توسعه سیستم، توسعه دهندگان ممکن است تصمیم به استفاده از “معماری میکرو سرویس” بگیرند. آنها ممکن است دریابند که این روش، سیستمی آسان برای توسعه ایجاد میکند چون که محدوده کامپوننت بسیار پایدار و اینترفیس ها نسبتاً پایدار هستند.

 

عملکرد

تأثیر معماری بر عملکرد سیستم کمتر از تأثیر معماری بر توسعه به چشم میخورد. تقریباً هر مشکل عملیاتی را میتوان با قرار دادن سخت افزار بیشتر در سیستم، بدون در هم ریختن معماری نرم افزار حل کرد.

شاید راه بهتر برای گفتن این موضوع، این باشد که معماری یک سیستم باعث میشود عملکرد سیستم به آسانی برای توسعه دهندگان نمایان شود. معماری باید عملکرد را نشان دهد. معماری سیستم باید Use case ، ویژگیها و رفتار مورد نیاز سیستم را به موجودیتهای عالی (First-class entities) که برای توسعه دهندگان قابل مشاهده است، ارتقا دهد. این کار درک سیستم را ساده کرده و بنابراین در توسعه و نگهداری سیستم کمک بسیاری دارد.

این متن فقط قسمتی از فصل 15 کتاب Clean Architecture می باشد.

0 پاسخ ها

دیدگاه خود را ثبت کنید

آیا می خواهید به بحث بپیوندید؟
در صورت تمایل از راهنمایی رایگان ما استفاده کنید!!

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *