در این فصل راجب اینکه معماری نرم افزار چیست صحبت میکنیم و نکات پیرامون ان صحبت میکنیم.
معمار نرم افزار کاملا با تصور شما تفاوت دارد و اینگونه نیست که دیگر نیاز به کدنویسی نداشته باشد. درست است که معمار نرم افزار باید در سطح انتزاع بالا کار کند و از جزییات بپرهیزد اما همچنان یک برنامه نویس است و باید برنامه نویسی انجام دهد. معمار نرم افزار باید با توجه به تجربه ی بالای خود بقیه افراد تیم را به سمت درست هدایت کنند . ان ها باید برنامه نویسی را انجام دهند تا بتوانند بهتر برنامه نویسان را درک کنند و مشکلات احتمالی که برای برنامه نویسان اعضای تیم ایجاد شود را پیشبینی کند.
معماری نرم افزار به نحوه ی ساختار دهی سیستم به منظور تحقق الزامات و نیاز های اصلی همزمان با تامین قابلیت تکامل و اپدیت و نگهداری ان است. اگر بخواهیم ساده تر بگوییم معماری نرم افزار ، تصمیمات اصلی در مورد ساختار یک سیستم نرم افزاری است. اگر معماری خوب باشد سیستم نرم افزاری ما نگهداری ساده تری خواهد داشت و هزینه ی کمتر مالی و انسانی برای ان خواهیم پرداخت ، اپدیت کردن و تکامل رساندن ان ساده تر باشد و می توان از ان به سادگی بارها استفاده ی مجدد کرد. اما اگر معماری ما ضعیف باشد پروسه توسعه ی نرم افزار ما بسیار دشوار می شود و تغییرات و اپدیت های اینده بسیار هزینه بر و سخت و گاها غیر ممکن می شود.
تصمیماتی که در معماری نرم افزار میگیریم بسیار مهم است . در معماری تصمیماتی گرفته می شود که تغییر ان در اینده بسیار سخت است . سخت بودن به این معناست که این تغییرات یا هزینه ی بسیار زیاد مالی یا زمانی دارند یا تقریبا غیر ممکن است . انتخاب زبان های برنامه نویسی که برای پروژه ی نرم افزار انتخاب می کنیم ، انتخاب فریم ورک ها ، انتخاب پایگاه داده مورد استفاده در پروژه و... از جمله تصمیمات مهمی است که در معماری نرم افزار میگیریم. بنظر من معماری نرم افزار مثل کاشتن درخت گردو است ، نتیجه و حاصل ان را در دراز مدت خواهیم دید.
در بخش توسعه در مورد این صحبت شد که معماری خوب ، فرایند توسعه را ساده تر میکند وقتی ساختار نرم افزار ما مشخص و ساده و واضح باشد برنامه نویسان راحت تر می توانند برنامه را توسعه بدهند یا تغییرات لازم را اعمال کنند. درست است که معماری به تنهایی نمی تواند عملکرد درست سیستم را گارانتی کند اما اگر معماری خوب باشد به برنامه نویسان کمک میکند که باگ ها و مشکلات را شناسایی کنند و عملکرد سیستم را بسیار بالا ببرند. معماری به شما این فرصت را می دهد تا که تصمیمات را جلو بندازید و زمانی تصمیمات را بگیریم که دانش و اگاهی کافی راجب به مسئله را داشته باشیم. در معماری نرم افزار جدید و مدرن از ادرس دهی های منطقی استفاده میکنیم ، این کار باعث می شود تا اجزای مختلف سیستم را خارج از موقعیت فیزیکی ان ها مدیریت کنیم که کار ویزایش و تغییرات را بسیار ساده تر برای ما می کند.
همانطور که از نام این فصل مشخص است این فصل در مورد این است که معماری نرم افزار باید به گونه ای طراحی شود که از جزییات خاص مثل تکنولوژی ها یا فریم ورک ها و .. مستقل باشد. همچنین قسمت های مختلف به هم دیگه وابسته نباشند و استقلال داشته باشند تا تیم های توسعه بتونن به صورت موازی و بدون اینکه با همدیگه تداخل داشته باشند کار هاشونو بکنن.
در معماری نرم افزار بسیار مهم است که ساختار ما به گونه ای باشد که تغییر در یک قسمت یا واحد تاثیری در بخش ها و قسمت های دیگه نداشته باشه. به این مفهوم جدا سازی میگویند.
قابلیت دیپلوی مستقل در این فصل گفته شد به این معناست که به توسعه دهندگان این امکان را بدهد تا قسمت های مختلف یک نرم افزار رابه صورت مستقل از یکدیگر دیپلوی کنند.
اگر یوز کیس ها به درستی از یکدیگر جاداسازی شوند تیم های توسعه می توانند به سادگی بدون تداخل با یکدیگر کار کنند. هر یوز کیس به نوعی مجموعه ای از عملیات هاست این عملیات ها نشان دهنده ی تعاملات کاربر با سیستم هستند.
یک معماری خوب به ما این اجازه را می دهد تا بتوانیم با تغییراتی که پیش می اید همچنان بتوانیم جدا سازی را به خوبی انجام دهیم.
در نرم افزار ها از لایه بندی برای تقسیم وظایف مختلف استفاده می شود. جدا کردن این لایه ها و وظایف از یکدیگر کار ما را راحت میکنید تا به صورت مستقل هر لایه را نگهداری کنیم. باید از ادغام بی مورد یوزر کیس ها بشدت بپرهیزید حتی اگر که ساختار ظاهری ان ها یکسان باشد باز هم با گذشت زمان این یوزکیس ها احتمال دارد تغییر کنند و با یکدیگر فرق کنند. تا جای ممکن سعی کنید که یوز کیس هارا از هم مستقل کنید.
جدا سازی هایی که در این فصل راجب ان صحبت کردیم میتواند در سطوح مختلفی باشد ، سطح کد منبع ، سطح دیپلوی ، سطح سرویس و ... انتخاب بین این سطج ها بستگی به نیاز ها و ویژگی های پروژه نرم افزاری ما دارد.
در طول توسعه برنامه باید همیشه مراقب باشیم که کد ها را بی مورد تکرار نکنیم ، بعضی وقتا این تکرار از قصد است و برنامه نویس هدفی پشت این کار دارد در این موارد مشکلی ندارد اما باید مراقب بود تا جای ممکن از کپی های بی مورد بپرهیزیم زیرا باعث انومالی در سیستم نرم افزاری ما می شوند.
در گذر زمان شاید نیاز ها یا نحوه ی دیکاپلینگ تغییر کند ، یک معمار خوب و یک معماری نرم افزار خوب باید بتواند این تغییرات را پیشبینی کند و سیستم نرم افزاری را برای این تغییرات از قبل اماده کند. همچنین یک معمار خوب باید این اجازه را بدهد که حالت های جدا سازی با توجه به نیاز های پروژه تغییر کند.
موضوع اصلی که در این فصل مطرح می شود چگونگی کشیدن مرز ها در معماری سیستم های نرم افزاری است . این مرز ها به ما کمک می کنند تغییراتی که در یک بخش از نرم افزار انجام می دهیم بقیه قسمت ها و بخش های نرم افزار مارا تحت تاثیر قرار ندهند.
مرز ها بین قسمت هایی کشیده می شوند که تغییرات ان ها همدیگه رو تحت تاثیر نذارند . مثل بین رابط کاربری و قوانین کسب و کار باید مرز کشیده شود و از همه دیگه جدا باشند.
معماری پلاگین به این صورت است که قسمت های نرم افزار که قابل تعویض هستند جدا باشند از بقیه بخش ها . با استفاده از معماری پلاگین مثلا پایگاه داده سیستم نرم افزاری را عوض میکنیم و بقیه قسمت های سیستم نرم افزاری ما تغییری نمیکند. به جای اینبکه یک برنامه ثابت و واحد بسازیم ، می توانیم برنامه امان را به قسمت های کوچک تر تقسیم کنیم که به ان ها پلاگین می گویند و به ساده قابل تعویض و تغییر و ارتقا هستند. در دنیای امروز که تکنولوژی به سرعت پیشرفت میکند استفاده از این معماری بسیار کار امد است . زیرا می توانیم قسمت های مختلف سیستم نرم افزاری خودمان را پلاگین های بروز تر و اپ تو دیت جایگذاری کنیم.
اصل وابستگی معکوس به این معناست که به قسمت های بالاتر و اصلی تر نرم افزار نباید به قسمت های جزئی تر و پایین تر وابسته باشند. مثلا قوانین کسب و کار که جزو قسمت های اصلی سیستم نرم افزاری هستند نباید به پایگاه داده که یک قسمت سطح پایین تر نرم افزار است وابسته باشند و باید بر عکس ان باشد.
اصل مسئولیت یکتا این را میگوید که هر قسمت از نرم افزار باید فقط یک دلیل برای تغییر داشته باشد. که ما با استفاده از مرزها ، قسمت های مختلف را جدا میکنیم که تغییرات بر بقیه قسمت ها تاثیری نداشته باشه.
در این فصل به بررسی چگونگی تعریف و تشخیص مرزها و اهمیت ان ها در طراحی یک سیستم می پردازد. معماری سیستم ها توسط مجوعه از اجزای نرم افزار و مرزهایی که انها را از یکدیگر جدا میکند تعریف میشوند. این اجزا در سیستم نرم افزاری باید با یکدیگر ارتباط بر قرار کنند. این ارتباطات باید جوری مدیریت شوند تا از قاطی شدن و وابستگی های بی مورد جلوگیری شود . این دقیقا اصلی ترین دلیل ایجاد مرز ها هستند. در زمان اجرا زمانی که یک تابع از یک سمت مرز یک تابع دیگه رو از سمت دیگه ی مرز فراخوانی کند می گویند از مرز عبور کرده است. زمانی که مشتری هایی با سطح بالاتر بخواهند از خدمات سطح پایین تر استفاده کنند ، بحران معماری ایجاد می شود. برای رفع این بحران ما از روش هایی نانند پلی مورفیسم دینامیکی استفاده میکنیم. نخ ها مکانیزم هایی هستند که بکد ما این اجازه را می دهند که به صورت همزمان اجرا شوند. مولفه های مستقر به صورا واحد های قابل اجرا می باشند که بدون نیاز به کامپایل مجدد قابل استفاده هستند. فرایند های محلی در یک سیستم اجرا می شوند اما در فضاهای مموری مجزا قرار دارند. فرایند هایی که می توانند در سیستم های مختلف و حتی مکان های فیزیکی مختلف اجرا شوند را خدمات یا سرویس می گویند. امروزه در بیشتر سیستم های نرم افزاری از ترکیبی از چند نوع مرز مختلف استفاده می شود. هر کدام از این مرز ها خصوصیات و ویژگیهای خاص خود را دارند و با توجه به نیاز ها و ویژگی هایی که پروژه داره ، استفاده می شوند .
در این فصل راجب شرح خطی مشی صحبت میکنیم . خط مشی نرم افزار را تقریبا می توان قوانین و سیاست های سیستم ترجمه کرد که می تواند به چگونگی محاسبه قوانین کسب و کار ، چگونگی قالب بندی گزارش ها و.... توضیحات دیگر شکسته شود.
هنر معماری نرم افزار این است که بتواند این قوانین را از یکدیگر جداسازی کند و چیدمان ان هارا بر اساس تغییراتشان انجام دهد. اگر دو تغییر در برای دو قانون با یک دلیل مشترک و در زمان یکسان اتفاق بیفتد باید در یک قسمت قرار بگیرند ولی اگر دلایل یا حتی زمان ان ها متفاوت باشد باید در قسمت های جداگانه ای قرار بگیرند.
معماران نرم افزار این قوانین را در نمودار های بدون حلقه قرار می دهند که این نمودار ها وابستگی میان اجزای مختلف را نشان می دهند. در یک معماری خوب وابستگی ها بر اساس سطج اجزا مشخص می شوند و باید اجزای سطح پایین وابسته به اجزای سطح بالای سیستم ما باشند.
معیار بالا پایین بودن سطح ، فاصله ی ان قانون از ورودی ها و خروجی هاست و هر چه قدر یک قانون از ورودی ها و خروجی ها دور تر باشد سطح ان بالاتری دارد و هر چه نزدیک تر باشد سطح پایین تری دارد. بیاید یک مثال بزنیم مثبلا در برنامه ی رمز نگاری قسمت ترجمه رمز ها از قسمت ورودی ها و خروجی ها دورتر است پس بالاترین سطح را در سیستم نرم افزاری دارد.
در یک معماری نرم افزار خوب وابستگی های کد با جریان داده همیشه همسو نیست و هدف از جداسازی این دو کاهش اثر تغییرات است . مثلا همان مثال قبلی که گفتم ، در نرم افزار رمز نگار اگه یک دستگاه ورودی / خروجی تغییر کند ، الگریتم رمزنگاری و ترجمه تغییر نمیکند یا تغییر بسیار کمی دارد.
در این فصل در مورد قوانین کسب و کار صحبت شده است . قوانین کسب و کار به زبان ساده به قوانین ، دستور العمل ها و سازوکار هایی که در یک کسب و کار یا بیزنس باعث کسب درامد و تولید پول یا کاهش هزینه ها و صرفه جویی شود قوانین کسب و کار می گویند. اگر قوانین به صورت دستی هم استفاده شوند همین تاثیر را دارند. مثلا اگر ما یک فروشگاه داریم و محصولات رو به صورت قصطی میفروشیم فرقی ندارد که سودی که به ازای فروش قسطی میگیریم توسط نرم افزار محاصبه شود یا به صورت دستی ، در هر صورت به شرکت سود میرسد زیرا این یکی از قوانین کسب و کار فروشگاه ماست.
در این فصل موجودیت هارا هم توضیح داده. طبق تعریف کتاب موجودیت ، یک شیء در سیستم های کامپیوتری است که مجموعه قوانین اساسی کسب و کار و همچنین داده های مرتبط با ان را اجرا می کند.
اما همه ی قوانین کسب و کار مثل موجودیت ها نیستند ، بعضی از این قوانین با تعریف کردن چگونگی عملکرد یک سیستم خودکار ، کسب درامد و تولید پول میکنند ، یا در هزینه های شرکت صرفه جویی میکنند. توجه کنید که این قوانین فقط در محیط اتوماتیک معنی دارد.
در مورد مدل های درخواست و پاسخ هم صبحت شد که متاسفانه خیلی متوجه نشدم چی میگه :)
اگر بخواهیم این فصل را جمع بندی کنیم میتوانیم بگوییم در حقیقت قوانین کسب و کار دلیل ساخت سیستم های نرم افزاری هستند . اگر قوانین کسب و کار نباشند دلیلی برای تولید سیستم های نرم افزاری نداریم . قوانین کسب و کار هسته و مرکزی ترین قسمت سیستم نرم افزاری ما هستند. باید دقت کنیم که ان ها به دیگر اجزای سیستم وابستگی نداشته باشند و کاملا مسقل باشند تا در سیستم های مختلف بتوانیم از ان استفاده کنیم.
معماری نرم افزار نباید فقط ابزار های استفاده شده در نرم افزار ، فریم ورک ها ، زبان های برنامه نویسی و... را نشان بدهد بلکه باید ویژگی ها و کاربرد های اصلی برنامه را نشان بدهد. مثلا وقتی نقشه ی یک مدرسه را میبینیم از ویژگی هایی که توی نقشه است متوجه میشویم که این نقشه ، نقشه ی مدرسه است و تمامی ویژگی های مهم ان را نشان میدهد نه اینکه فقط بگویید با چه موادی ساخته شده این ساختمان. در معماری نرم افزار هم باید به گونه ای عمل کنیم که تمامی ویژگی ها و کاربرد های اصلی سیستم نرم افزاری مارا نشان بدهد. یک معماری شگفت انگیز ، تصمیات مربوط به فریم ورک ها ، زبان های برنامه نویسی ، دیتابیس و.... را به تاخیز می اندازد و بر ویژگی ها و کاربرد های اصلی برنامه تاکیید دارد و ان هارا از دیگر ویژگی های جانبی جدا می کند. معماری نرم افزار شما باید سیستم نرم افزاری شمارا توضیح بدهد مثلا اگر یک سیستم نرم افزاری بانکی می سازید ، برنامه نویسان دیگری که به معماری نرم افزار شما نگاه می کنند در نگاه اول متوجه شوند که این یک سیستم بانکی است.
فریم ورک ها ابزاری ها قدرتمندی هستند اما نباید معماری کلی نرم افزار مارا تعیین کند. باید به گونه ای از فریم ورک ها استفاده کرد که معماری کلی نرم افزار را تحت تاثیر قرار ندهند. برای وب هم به همین صورت است . وب هم صرفا یک مکانیسم تحویل یا رابط کاربری است و نباید معماری اصلی نرم افزار مارا تعیین کند و معماری کلی نرم افزار را تغییر دهد. یک معماری شگفت انگیز باید امکان تست کردن قسمت های مختلف سیستم نرم افزاری را بدون نیاز به وابستگی ها مانند فریم ورک و... فراهم کند. یعنی بتوانیم ویژگی های اصلی و کاربرد های نرم افزار را تست کنیم بدون اینکه به موارد خارجی وابستگی داشته باشیم.
هدف اصلی از طراحی معماری نرم افزار در این فصل ( در هر فصل یک هدف اصلی دارد ) اطمینان از پشتیبانی از کاربر های و ویژگی های اصلی سیستم است و معماری باید امکان اتخاذ تصمیم ها را در مورد ابزرا ها و تکنولوژی های جدید که در اینده می اید را فراهم کند نه اینکه محدود کننده باشد.
این فصل هم نام کتاب است پس میتوان گفت یکی از فصل های مهم است . از گذشته تا الان دیدگاه ها و روش های متفاوتی برای معماری وجود داشته است . درست است که هر کدام از معماری های نرم افزار جزئیات و ویژگی های خودشان را دارند اما هدف اصلی همه این معماری ها یک چیز است ، جدا سازی مسئولیت ها .
هر چه به داخل تر می رویم و وارد جزئیات می شویم سطح انتزاع نرم افزار بالاتر می رود . بیرونی ترین دایره ها مکانسیم ها هستند و داخلی ترین دایره ها سیساست ها یا خط مشی ها هستند. وابستگی ها باید فقط به داخل اشاره کنند و دایره های داخلی نباید چیزی راجب به یک دایره ی خارجی بدانند.
برای انتقال داده از یک دایره به دایره دیگر باید به جای اینکه یک لایه داخلی به یک لایه خارجی مستقیما وابسته باشد و از یک واسطه یا اینترفیس استفاده شود که لایه خارجی اجرایی کرده باشد. بعضی از داده ها که عبور می کنند معمولا ساختار داده ساده ای دارند. داده ها نباید هیچ وابستگی داشته باشند که قانون وابستگی را نقض کنند یا به زبان ساده تر نباید مستقیما از یک پایگاه داده یا فریم ورک خارجی وارد شوند.
معماری هایی که گفتیم ویژگی های اصلی دارند که در این فصل اشاره شدند. سیستم بر اساس یک کتابخانه خاص ساخته نمی شود و از فریم ورک ها استقلال دارند. قوانین تجاری بدون واسط کاربری یا پایگاه های داده قابل تست هستند همچنین می توان واسطه کاربری را تغییر داد بدون اینکه قوانین تجاری و کسب و کار را تغییر کند. پایگاه داده را نیز میتوان تغییر داد و کاملا مستقل است . چند بخش دیگر هم در این فصل تعریف شده است . مانند موجودیت ها که شامل قوانین تجاری کلی سیستم هستند ، یوز کیس ها که شامل قوانین خاص نرم افزاری هستند و... . رعایت این قوانین که در این فصل گفته شد باعث می شود تا سیستم نرم افزاری تولیدی ما قابل آزمون باشد و وقتی قسمت های خارجی مانند پایگاه داده ، رابط کاربری و ... منسوخ شود می توان با حداقل هزینه ان هارا تعویض کرد و ان هارا با تکنولوژی روز دنیا بروزرسانی کرد. همچنین باعث می شود سیستم ها مقایسه پذیر شوند و نگهداری ان ها بسیار ساده تر و کم هزینه تر شوند.
در این فصل در مورد humble و presenter صحبت میکنیم . الگو شی humble برای جدا کردن رفتاری های خست از اسان در تست به وجود امده اند . رفتار ها به دو کلاس تقسیم می شوند یک سخت تست می شوند و اون دیگری اسان . با استفاده از این الگو مثلا رابط های کاربری سخت تست می شوند . ما می توانیم رفتار هایی مرتبط با رابط کاربری و رفتار های قابل تست رو از همیدگه جدا کنیم و این دو رفتار را به صورت دو کلاس ارائه دهنده و نمایش دسته بندی کنیم . view شیء سخت تست است و کد در ان به حداقل ممکل محدود شده است و presenter وظیفه دارد داده ها را قالب بندی کرده و view منتقل کند. الگوی شی humble جدا سازی رفتار های یک مرز معماری را تعریف میکنند که کمک میکند معماری ها قابل تست شوند. در هر مرز معماری الگوی شیء فروتن را میتوانیم مشاهده کنیم . استفاده از این الگو در مرز های معماری تست پذیری کل سیستم را افزایش خواهد داد.
در این فصل به ادامه صحبتمون در مورد مرز ها میپردازیم . در بعضی وقتا نیازی به تعریف یک مرز معماری کامل نیست، بعضی وقتا ایجاد یک مرز کامل زمان بر و پر هزینه است ، برخی مواقع معماران نرم افزار امکان دارد تصمیم بگیرند تا به جای ایجاد یک مرز کامل از یک مرز جزئی استفاده کنند. این فصل در مورد همین مرز های جزئی است.
ایجاد کردن یک مرز معماری کامل هزینه های بسیاری را برای ما دارد مانند واسطه های چندشکلی ، ساختار های وردوی و خروجی و.... . در بعضی مواقع معماران نرم افزار پیشبینی کنند که در اینده شاید نیاز به مرز داشته باشند و باید ان را تعریف کنند اما در حال حاظر نیازی به ان مرز نیست ، در چنین شرایطی معمولا معماران تصمیم به تعریف یک مرز جزئی میکنند.
راهکار های مختلفی برای ایجاد مرز جزئی وجود دارد . یکی از این راه ها این است که تمامی کار های مورد نیاز برای ساختن مولفه های مستقل را بکنیم ولی تمامی این هارا در یک مولفه یکپارچه کنیم. روش ش مرز های یک بعدی به این صورت است که فقط یک سمت وابستگی را در نظر میگیریم . این کار ساده تر و کم هزینه تر از روش مرز های کامل است ولی در عین حال می تواند اماده سازی برای یک مرز معماری کامل باشد. اخرین سبکی که در این فصل معرفی می شود نمایه هست که یکی از ساده ترین هاست . این الگو از یک مرز ساده تر است که تنها یک کلاس نمایه تعریف می شود و حتی وابستگی های معکوسم چشم پوشی میکنیم. در پایان معمار باید تصمیم بگیرد که در کجا ممکن است یک مرز معماری وجود داشته باشد و این مرز به صورت کامل باید پیاده سازی شود یا جزئی شود.
در این فصل در مورد ساختار و معماری نرم افزار صبحت میکنیم . اکثر سیستم های ساده از سه بخش اصلی تشکیل شده اند. این سه بخش عبارتند از قوانین تجاری ، پایگاه داده و رابطه ی کاربری . این فکر که همه ی سیستم ها از همین سه بخش تشکیل شده اند اشتباه است و سیستم های بزرگ تر و پیچیده تر معمولا اجزای دیگری نیز دارند ولی میتوان این را با اطمینان گفت که اغلب سیستم ها این سه بخش را دارند و دیگر از این قدر ساده تر نیستند.
در این فصل یک بازی کامپیوتری را مثال زده است و این بخش ها را در ان مشخص کرده است. نکاتی که در مورد بازی است این است که می توانیم رابط کاربری متنی بازی را جدا کنیم تا بتوانیم ان را در سیستم عامل های مختلف تولید کنیم و بتوانیم در همه سیستم عامل ها اجرا شود. همچنین باید ذخیره سازه داده ها مستقل باشند ، مهم نیست که داده ها در کجا ذخیره می شوند ، اصل مهم این است که قوانین بازی نباید از جزئیات ذخیره سازی اگاه باشند.
در این فصل معماری تمیز را برای بار دیگر تعریف کرده است که به این معناست که باید به صورت مناسب و با دقت ساختاردهی و تقسیم و وظایف سیستم را مدیریت کرد . در سیستم های پیچیده تر ممکن است داده ها از چند مسیر مختلف عبور کنند ، به عنوان مثال ممکن است داده ها از طریق یک کامپیوتر لوکال به یک سرور منتقل شوند. الته حتی بازی های ساده ممکن است دارای قوانین و مکانیزم های پیچیده ای باشند . همه این ها نشان دهنده این است که در هر سیستمی می توانیم به مرزها و جدایی های معماری برخورد کنیم ، به عنوان معمار باید به طور مداوم به دنبال این مرز ها باشیم و وقتی لازم است ان ها را پیاده سازی کنیم .
در این فصل در مورد مولفه یا کامپوننت اصلی صحبت میکند. در هر سیستمی حداقل یک قسمت وجود دارد که باقی قسمت ها را ایجاد میکند و هماهنگی و نظارت بر باقی قسمت ها نیز به عهده ی ان بخش است . به این قسمت کامپوننت اصلی میگوند.
این قسمت وظایف مهمی دارد ، نقطه ورودی اولیه به سیستم است ، هیچ چیز جز سیستم عامل به ان وابسته نیست ، وظیفه ی ان ایجاد تمامی کارخانه ها استراتژی ها و دیگر امکانات جهانی است ، پس از ایجاد، کنترل را به قسمت‌های سطح بالای سیستم واگذار میکند و.... از مهم ترین وظایف کامپوننت اصلی هستند.
کامپوننت اصلی یک مؤلفه سطح پایین در معماری نرم‌افزار است.، مانند یک افزونه به نرم‌افزار است که شرایط اولیه را راه‌اندازی میکند و منابع خارجی را جمع‌آوری میکند. با تصور Main به عنوان یک افزونه، میتوان برای هر تنظیمات مختلف نرم‌افزار یک Main مختلف داشت (مانند توسعه، تست، تولید و .... )
در این فصل در مورد معماری های مبتنی بر سرویس های بزرگ و سرویس های کوچک یا میکرو صبحت میکنیم که اخیرا بسیار محبوب شده اند. دلیل محبوبیت بالای این معماری ها این است که به نظر می رسد که بخش های مختلف یک سیستم ( یعنی سرویس ها ) می توانند به صورت متسقل از یکدیگر کار کنند ، اما باید توجه کرد که این موضوع به طور کامل درست نیست .
فقط استفاده از سرویس ها به معنای داشتن یک معماری سرویس خوب برای سیستم نرم افزاری ما نیست ، معماری خوب در مورد چگونگی سازماندهی قسمت های مختلف یک سیستم و وابستگی سرویس ها و قسمت ها و.. به یکدیگر می گوید. سرویس هایی که فقط رفتار های برنامه را شکسته اند مانند دستورات تابع در کد هستند و همیشه برای معماری سیستم مهم نیستند. اما بعضی از این سرویس ها بسیار سودمند هستند مثلا زمانی که تسک ها را در فرایند ها یا سیستم های مختلف جدا کنند.
موضوع این فصل کتاب در مورد این است که ازمون ها بخشی از سیستم هستند مانند بقیه بخش های سیستم . یکی از سوال های رایج این است که ایا ازمون واقعا بخشی از ازمون هستند یا اینکه چه نوع ازمون هایی بخشی از سیستم هستند. پاسخ این است که دید معماری نرم افزار همه ازمون ها یکسان هستند و تفاوت مهمی بین ان ها نیست ، ازمون ها وابسته به قسمت های خاصی از هستند و هیچ بخشی از سیستم بع ازمون ها وابسته نیست.
در هنگام طراحی ازمون باید به نکات مهمی توجه کرد ، ازمون ها باید با سیستم هماهنگ باشد وگرنه می توانند کارایی لازم را ندارند و نگهداری از ان ها نیز سخت می شود. ازمون هایی که بیش از حد وابسته به سیستم باشند هنگام تغییرات سیستم دچار تغییرات زیادی می شوند که این موضوع خودش مشکلات خاص خودش را دارد. برای رفع این مشکلات باید طراحی سیستم و ازمون به نحوی باشه که بشه بدون استفاده از ui اونارو تست کرد. برای اینکار می توان از api ها استفاده کرد تا بدون ایجاد مشکلات امنیتی یا استفاده از منابع پر ازشمون سیستم نرم افزاری رو تست کنیم .
در این فصل در مورد اهمیت نگهداری نرم افزار در مقابل تغییرات سخت افزاری در محیط های توکار صحبت میکنیم . به صورت کلی نرم افزار ها منسوخ یا از رده خارج نمی شوند اما سخت افزار ها با گذر زمان منسوخ می شوند و باید تعویض شوند . مثلا ما دیگر از کامپیوتر های 20 سال پیش استفاده نمیکنیم . باید مراقب باشیم که نرم افزار های ما وابسته به سخت افزار نباشند تا این تغییر راحت باشد. اگر نرم افزار ما وابسته به سخت افزار ها یا فریم ورک ها باشد با گذر زمان و منسوخ شدن سخت افزار و فریمورک ، نرم افزار هم نابود می شود .
یکی از وظایف معمار نرم افزار این است که مرز بین نرم افزار و سخت افزار تعبیه کند تا از مشکلاتی که بالا مطرح کردم جلو گیری شود. همچنین در این فصل در مورد اهمیت معماری تمیز توکار در توسعه نرم افزار اشاره کرده است . طراحی معماری توکار تمیز امکان تست نرم افزار خارج از سخت افزار مقصد را برای ما ایجاد میکند و این امکان را به نرم افزار ما می دهد که بدون وابستگی به سخت افزار مقصد کار کند.
در این فصل در مورد نقش و اهمیت پایگاه داده در معماری سیستم های نرم افزاری بحث شده است. پایگاه داده، از دیدگاه معماری، به عنوان یک جزئیات تلقی میشود که در سطح عنصرهای معماری بلند مدت نیست و نباید به معماری سیستم نفوذ کند. پایگاه داده مثل یک جزئیات کوچک در مقایسه با ساختار کلی سیستم نرم‌افزاری است. ارتباط پایگاه داده با معماری سیستم نرم‌افزاری شبیه به ارتباط یک دستگیره درب با معماری خانه‌ی شماست. راحت تر بخوام بگم پایگاده داده خیلی برای معماری مهم نیست و اهمیت انچنانی ندارد. برای همین در فصل جزئیات به ان اشاره کرده است . اما مراقب باشید که پایگاه داده را با مدل داده قاطی نکنین ، استراکچری که به داده ها تو نرم افزار می دهیم بسیار مهم است و برای معماری مهم است . در کل باید حواسمان باشد که یک جزئیات سطح پایین مانند پایگاه داده وارد معماری شود و سیستم نرم افزاری مارا الوده کند.
پایگاه داده یک مکانیزم سطح پایین است که برای ذخیره کردن و دستری به داده ها استفاده می شود اما داده ها مدل داده را درست می کنند که برای معماری نرم افزار اهمیت بالایی دارند ولی پایگاه داده فقط یک وسیله یا تولز برای دسترسی به این داده هاست به همین خاطر جزو مکانیزم های سطح پایین حساب می شود.
موضوع دیگری که در این فصل صحبت شد پایگاه داده رابطه ای است . دلیل اهمیت این مدل این است که به خوبی می توانند با دیسک ها ارتباط برقرار کنند. دیسک ها برای دسترسی به داده ها بسیار کنند هستند که سیستم های مدیریت پایگاه داده از روش های مختلفی استفاده می کند تا سرعت کار را بالا ببرد . اگر از دیسک ها استفاده نکنیم و همه داده در حافظی رم ذخیره بشوند داده ها به شکل لیست های پیوندی ، درخت ها ، جداول هش و... ذخیره می شوند و با استفاده از پوینتر به ان ها دسترسی پیدا میکنیم . با گذشت زمان و پیشرفت های زیاد تکنولوژی دیسک ها منسوخ شدند و جای خود را به حافظ های موقت دادند .
درسته که پایگاه داده اهمیت بالایی دارد و به عنوان یک مکانیزم برای انتقال داده ها بین دیسک و حافظ موقت استفاده می شود ، اما نباید ان را در معماری دخیل کنیم . میشه پایگاه داده رو به صورت چداگانه از قوانین تجاوری و موارد کاربردی سیستم مدیریت کرد و وارد معماری نرم افزار نکردش.
این فصل در مورد تغییرات و نوسانات در طراحی و پیاده سازی سیستم های کامپیوتری صحبت می شود و به چگونگی توزیع قدرت پردازش می پردازد . همچنین می خواهد این را بیان کند که وب ، درست است که رابط کاربری است اما فقط یک جز از یک سیستم بزرگ تر است و نباید به عنوان تنها قسمت مهم سیستم در نظر گرفته شود. قدیم در بیشتر وقتا تمامی قدرت پردازش در یک مکان مرکزی مانند یک سرور جمع می کردند و بقیه دستگاها صرفا یک واسطه ی کاربری بودند. اما با گذشت زمان قدرت پردازش به دستگاه های محلی منتقل شد. البته چندین بار بین اینکه همه پردازش ها در یک مکان باشد یا تقسیم بشود بحث بود و مدادم جایگزین یکدیگر میشدند این دو روش.
اصلی ترین نکته که در این فصل مطرح می شود این است که وب به عنوان یک رابط کاربری فقط یکی از جزئیات سیستم است و نباید معماران در طراحی معماری نرم افزار خود قوانین کسب و کار و دیگر اجزای سطح بالا را با جزئیات فنی مانند رابط کاربری قاطی کنن و باید مستقل باشند. اگر این نکته را رعایت کنند هر وقت تغییراتی در رابطه کاربری یا تکنولوژی های مورد استفاده قرار بگیرد که بسیار هم اتفاق می افتد ، نیاز به تغیر کلی سیستم نداریم. مثلا شما بارها می بینین که شرکت های بزرگ نرم افزاری داخل و خارجی ظاهر وبسایت خود را عوض میکنند. تصور کنین که امازون یا دیجی کالا هر بار که ظاهر خود را می خواهند عوض کنند مجبور شوند کل سیستم نرم افزار خود را کامل عوض کنند چه هزینه زیادی باید پرداخت کنند .
درست است که این جدا سازی ها و محافظ از لوجیک اصلی سیستم در برابر تغییرات فنی و تکنولوژی بسیار سخت است ، اما با توجه سرعت بالای پیشرفت تکنولوژی بسیار واجب و ضروری است .
در این فصل در مورد تاثیر فریم ورک ها در معماری در نرم افزار صحبت می کند. فریم ورک ها ابزار هایی هستند که به برنامه نویسان کمک می کند تا برنامه ها را سریع تر و استاندارد تر درست کنند. فریم ورک ها بسیار قدرتمند هستند و بسیاری از ان ها رایگان در دسترس برنامه نویسان قرار گرفته اند و کمک بسیاری در تولید نرم افزار ها می کنند اما باید توجه داشته باشید که این ها به هیچ عنوان جزو معماری نرم افزار نیسند و تنها یک ابزار مناسب برای توسعه سیستم های نرم افزاری هستند. اکثر این فریم ورک ها را برنامه نویسان برای رفع مشکلات خودشان یا تیم و شرکت خودشان نوشته اند اما با توجه به کیفیت بالای ان ها و استقبال دیگران از ان در اختیار عموم قرار گرفته اند.
اما استفاده از فریم ورک ها خطرات خود را دارند . باید مراقب باشید که برنامه شما به هیچ عنوان وابسته به فریم ورک ها نشوند زیر ممکن است بعضی از قسمت های ان خوب توسعه داده نشده باشد و در روند توسعه نرم افزار شما دچار مشکل شوید. در ابتدای کار فریم ورک ها بسیار کمک کننده هستند مخصوصا زمانی که نرم افزار شما کوچک است و ویژگی های خاصی ندارد . اما زمانی که نرم افزار شما بزرگ تر و پیشرفته تر شوند فریم ورک ها پاسخگوی نیاز های شما نیستند و دست و پای شمارا میگیرند و نیاز های شما از توانایی های فریم ورک خارج می شود. همچنین امکان دارد فریم ورک ها اپدیت بشوند و ویژگی های قدیمی که شما سیستم نرم افزاری خودتونو با اون ساختین از فریم ورک حذف بشود و شما دیگر نتوانید فریم ورک خودتون را اپدیت کنین و باید از همون نسخه های قدیمی استفاده کنید که ممکن است باگ های امنیتی و.. داشته باشد و از امکانات بروز فریم ورک محروم شوید.
پس اگر بخواهیم به زبان ساده بگوییم بهترین کار این است که فریم ورک ها وابسته نشوید !!. به جای اینکه فریم ورک هارا جزوی از برنامه ی اصلی خودتون بکنین ، اون هارو تو یه قسمت جداگانه و مستقل قرار دهید و اجازه ندهید وارد کد های اصلی برنامه شما بشوند.
در این فصل در مورد یک نرم افزاری برای وبسایتی که ویدیو می فروشد صحبت می کند. یک دسته ویدیو داریم که میتوانیم به فرد یا شرکت ها بفروشیم . برای طراحی معماری نرم افزار سیستم ابتدا باید اکتر ها و یوز کیس هارا تعریف کنیم . در این مثال چهار اکتر داریم ، مدیر وبسایت ، نویسنده ویدیو ، کسی که ویدیو را میخرد و کسی که ویدیو را می بیند. پس تعریف بازیگران و یوز کیس ها معماری کامپوننت ها ایجاد میشود. معماری کامپوننت یک نقشه یا معماری از چگونگی تقسیم بندی و تعامل بخش های مختلف یک سیستم است.
مطالعه موردی روشی است برای نشان دادن چگونگی پیاده سازی قوانین و مفاهیم و در مثال های دنیای واقعی. انطعاف پذیری در تحویل به ای ن معناست که با استفاده از معماری نرم افزار خوب می شود اجزای سیستم را به هر شکل که دوست دارید تحویل دهید و با توجه نیاز ها حتی این تحویل را تغییر دهید.
در این فصل در مورد چگونگی سازماندهی کد ها در یک پروژه صحبت می کند.
ساختار لایه ای : در این روش کد ها بر اساس عملکردی فنی که دارند در لای های افقی تقسیم می شوند و کد ها مشابه از نظر وظایف در یک گروه قرار میگیرند که در عمده نرم افزار ها به سه قسمت تقسیم می شوند . لایه وب ، لایه قوانین کسب و کار و لایه دسترسی به داده ها .
ساختار بر اساس ویژگی : در این روش همانطور که از نامش پیداست کد ها بر اساس ویژگی هایشان یا عناصر اصلی تقسیم می شوند. تمامی کلاس ها یا اینتر فیس های مرتبط با یک ویژگی خاص در یک دسته قرار می گیرند.
پورت ها و اداپتر ها : در این روش به جداسای کد های معتمد بر دامنه از جزئیات فنی می پردازد. به زبان ساده تر کد های مرتبط با دامنه در داخل قرار دارند و کد های مرتبط با دنیای خارجی در خارج قرار میگیرند. در این روش کد های خارجی به داخلی وابسته باشند .
ساختار مرتبط با کامپوننت : این روش در حقیت ترکیبی از روش های قبلیست که تازه گفته شد . در این روش به ایجاد بسته های کدی مرتبط با کامپوننت های چندگانه می پردازد. این روش به سمت معماری های مبتنی بر سرویس مانند معماری میکرو سرویس میرود . این روش را نویسنده ی کتاب که اسمش یادم نیست توصیه میکند. کد ها بر اساس کامپوننت های خود پروژه تقسیم می شوند و هر کامپوننت بسته ای از کلاس ها و اینترفیس های مرتبط ب یکی ویژگی یا بخشی از سیستم را در خود دارد . این روش می تواند کد را از لایه بندی افقی و عمودی بهبود دهد.
