معماری چیست
به طور کلی ارائه تعریف کلی و دقیق برای معماری نرم افزار غیر ممکن است. به طور کلی معماری خوب یک نرم افزار باعث میشود نرم افزار قابل توسعه ، قابل درک و قابل نگهداری باشد. به طور کلی معماری خوب خلاقیت توسعه دهنده ها را افزایش داده و هزینه نگهداری سیستم را کاهش میدهد. یک معمار خوب سعی میکند که تا جایی که امکان دارد کمترین تصمیمات را بگیرد زیرا هرچقدر دیرتر تصمیمات گرفته شود امکان این که تصمیمات انطباق بیشتری با نظر تیم محصول یا نیازمندی های کاربر داشته باشد.
استقلال
در معماری چهار مورد مهم وجود دارد که باید به آن توجه کرد:
عملکرد کلی سیستم و کاری که باید انجام دهد
قابلیت نگهداری سیستم
قابلیت توسعه سیستم
قابلیت deploy
در معماری خوب به این چهار مورد به صورت مستقل توجه میشود و هر کدام از این موارد در لایه های جدا به صورت مستقل توسعه داده میشوند.
به عنوان مثال یک سیستم نرم افزاری ممکن است عملکرد های متفاوتی داشته باشد اگر هر عملکرد در لایه ای مجزا پیاده سازی شود در صورت تغییر یک عملکرد تنها کافی است که لایه مورد نظر تغییر کند. همچنین امکان اضافه کردن لایه های جدید به راحتی وجود دارد. این مورد مانند اصل single responsibility ولی برای لایه های مختلف نرم افزار است.
حسن دیگر استفاده از این ساختار این است که هر لایه با توجه به کاربرد میتواند در سروری مجزا اجرا شود و هر بخش پهنای باند بیشتری داشته باشد.
مورد دیگر این است که هر لایه میتواند توست تیمی مجزا توسعه داده شود و هر تیم لزومی ندارد که تمام موارد مربوط به کسب و کار و کارکرد دقیق لایه های دیگر را بشناسد.
این جدا سازی لایه ها میتواند راه های مختلفی داشته باشد از جمله: جدا سازی کد ها از یکدیگر، جدا سازی فایل های اجرایی و جدا سازی سرویس ها
یک معماری خوب اجازه میدهد که یک پروژه ابتدا به صورت monolithic توسعه داده شود سپس در صورت نیاز با بزرگتر شدن پروژه به سمت جدا سازی سرویس ها برود و در نهایت به سمت معماری micro-service حرکت کند. ولی در هر زمان امکان برگشت به معماری monolithic سابق را داشته باشد.
مرزها
نکته بسیار مهم در معماری یک سیستم رعایت مرز بندی بین اجزا مختلف (به عنوان مثال بین UI , دیتابیس ، موارد مربوط به بیزینس و ،،،) میباشد. همچنین علاوه بر این که این موارد باید از هم مجزا باشند ، خیلی مهم است که به جز موارد موبوط به بیزینس پروژه بقیه نصمیمات زود گرفته تشود به عنوان مثال از چه دیتابیسی استفاده شود یا چه نوع وب سرویسی باید استفاده شود.
قوانین و سطح ها
یک برنامه کامپیوتری در اصل یک سری قوانین و دستورالعمل ها را پیاده سازی میکند. در برنامه های بزرگ که تعداد زیادی از قوانین را پیاده سازی میکنند بهتر است این قوانین به صورت مجزا و در لایه مجزا پیاده سازی شوند. به طور کلی قوانین سطح پایین به قوانین سطح بالا وابسته هستند.
قوانین کسب و کاری
یک سری از قوانین کسب و کار حیاتی هستند و حتی اگر هیچ سیستم کامپیوتری وجود نداشت باز هم این قوانین ثابت بودند (مانند نرخ بهره در بانک ها). این قوانین قابل تغییر نیستند و باید به شکل کامل پیاده سازی شوند. داده های این بخش از کسب و کار نیز حیاتی است و حتی اگر سیستم کامپیوتری وجود نداشت این داده ها موجود بود.
به ابجکت های که این اطلاعات را نگهداری میکنند Entity میگوییم. Entity ها داده ها و قوانین مربوط به کسب و کار را کنار هم جمع میکنند.
البته تمام قوانین کسب و کار entity محسوب نمیشوند.
معماری ترس!
معماری نرم افزار نباید وابسته به فریم ورک باشد و به طور کلی باید نشان دهنده قوانین کسب و کاری باشد. به عنوان مثال وقتی به سطح بالای معماری یک نرم افزار بانکی نگاه میکنیم باید متوجه شویم که این معماری مربوط به یک نرم افزار بانکی است نه این که فقط متوجه فریم ورک مورد استفاده بشویم.
به طور کلی یک معماری نباید وابسته به فریم ورک , دیتابیس و ،،، باشد.
معماری تمیز
در طول سال ها معماری های مختلفی برای نرم افزار مطرح شد. این معماری ها در چند موضوع مشترک بودند. اول این که مستقل از فریم ورک یا ابزار مورد استفاده بودند. دوم این که قابل تست شدن بودند و به طور کلی مستقل از دیتابیس ، UI و قوانین بیزینس بودند.
تست
یک معماری خوب باید قابل تست کردم باشد به این منظور بهتر است بخش های که unit test نوشتن برای آسان است از بهش هایی که توسعه unit test برایشان سخت است مستقل باشند به عنوان مثال نوشتن تست برای بخش UI سخت و چالش برانگیز است پس بهتر است بخش UI از بخش رفتار نرم افزار مجزا باشد.
