https://virgool.ir/feed/@m_14355741fa2026-11-11 23:46:11https://files.virgool.ir/upload/users/2921862/avatar/wH2u1z.jpghttps://virgool.ir/@m_14355741https://virgool.ir/@m_14355741/مروری-بر-سخنرانی-های-معماری-سازمانی-riai0kkojfgaمعماری سازمانی یک چارچوب است که ساختار و ارتباطات داخلی یک سازمان را تعیین می‌کند. این ساختار نقشه‌ای است که نحوه تقسیم کار و تعامل بین واحدها و افراد در سازمان را نشان می‌دهد. در ادامه، عناصر کلیدی معماری سازمانی را شرح می‌دهم: 1. سلسله مراتب سازمانی: - توضیح دهنده ساختار سلسله مراتبی سازمان، از سطوح مختلف مدیریتی و اجرایی تا سطح کارگران. 2. تقسیم بندی کار: - نشان دهنده چگونگی تقسیم وظایف و مسئولیت‌ها بین افراد و واحدهای مختلف در سازمان. 3. ساختار واحد: - شامل اطلاعات در مورد واحدهای مختلف سازمان و ارتباطات آنها با یکدیگر. 4. فرآیندها و روابط سازمانی: - نحوه جریان اطلاعات، تصمیم‌گیری و هماهنگی درون سازمان را تعیین می‌کند. 5. فرهنگ سازمانی: - شامل اصول، ارزش‌ها و رفتارهای مشترک در سازمان است که تعیین‌کننده تفکر و عملکرد اعضا می‌باشد. 6. تعهد به کارکنان: - نحوه پاداش‌دهی، ارتقاء و توسعه کارکنان را مشخص می‌کند. 7. مستندات سازمانی: - شامل سند مواردی مانند نقشه‌ها، فرآیندها، سیاست‌ها و الزامات سازمانی است. معماری سازمانی با همه این جوانب به سازمان کمک می‌کند تا بهبود یابد، به صورت کارآمد عمل کند و اهداف خود را دستیابی پیش ببرد.محمد گنجیمحمد گنجیSat, 30 Dec 2023 00:59:08 +0330https://virgool.ir/@m_14355741/ارائه-مطالبی-آموزشی-در-باب-15-موضوع-در-قالب-تمرین-درس-معماری-نرم-افزار-دانشگاه-شهید-بهشتی-jchpzir5mwx2مفهوم 1 ) مبحث Modular Monolithic- ماژولاریته در معماری نرم‌افزار:ماژولاریته در معماری نرم‌افزار به معنای تقسیم سیستم به بخش‌های مستقل (ماژول‌ها) با وظایف مشخص است. هر ماژول وظیفه خاصی را انجام می‌دهد و با ماژول‌های دیگر ارتباطات مشخصی دارد. این ایده به توسعه‌پذیری، قابلیت‌های بازنگری و نگهداری آسانتر کمک می‌کند. این سیاست از اصول اصلی مهندسی نرم‌افزار به شمار می‌آید.-مونولیتیک در معماری نرم‌افزار:سیستم‌های مونولیتیک به صورت یکپارچه و در یک واحد اجرایی (مانند یک برنامه یا سرویس) عمل می‌کنند. همه وظایف و اجزای سیستم در یک محیط اجرایی ترکیب شده‌اند و به صورت یک بلوک عظیم عمل می‌کنند. این معماری معمولاً ساده‌تر به نظر می‌رسد و مدیریت آن نسبت به معماری‌های پیچیده‌تر ماژولار، ساده‌تر است.-ماژولار مونولیتیک:حالا، ماژولار مونولیتیک یک ترکیب از این دو مفهوم است. در این معماری، سیستم به شکل مونولیتیک طراحی شده است، اما به صورت ماژولار تقسیم می‌شود. این به معنای داشتن بخش‌ها یا ماژول‌هایی مستقل درون سیستم است که وظایف خود را انجام می‌دهند و با ارتباطات مشخص به یکدیگر وصل شده‌اند. این رویکرد سعی در ایجاد تعادل میان سادگی مدیریت یکپارچه و امکانات ماژولار برای توسعه و نگهداری بهتر سیستم دارد.مفهوم 2) AWSبه عنوان Amazon Web Services شناخته می‌شود و یک پلتفرم ابری است که توسط شرکت آمازون ارائه می‌شود . این سرویس‌ها به شرکت‌ها و توسعه‌دهندگان این امکان را می‌دهند تا برنامه‌ها و سرویس‌های خود را بر روی زیرساخت ابری AWS اجرا کنند. در بحث معماری نرم افزار ، AWS به عنوان یک سرویس ابری بسیار گسترده و جامع شناخته می‌شود و به توسعه‌دهندگان این امکان را می‌دهد تا برنامه‌های خود را بر روی زیرساخت ابری قدرتمند و مقیاس پذیر آن اجرا کنند . در ادامه ، چند مفهوم اساسی در معماری نرم افزار با استفاده از سرویس‌های AWS را توضیح میدهیم :1) EC2 (Elastic Compute Cloud)- مفهوم EC2 : یک سرویس ابری است که امکان اجرای ماشین‌های مجازی (VMs) را در محیط ابری AWS فراهم می‌کند.- به عنوان مثال : اگر ما یک برنامه وب داشته باشیم که نیاز به منابع محاسباتی متغیر دارد ، می‌توانیم از EC2 برای راه‌اندازی و مدیریت سرورهای مجازی با مشخصات دلخواه خود استفاده کنیم .2) S3 (Simple Storage Service)- مفهوم S3 : یک سرویس ذخیره‌سازی ابری است که امکان ذخیره و بازیابی داده‌ها در فضای شیء فراهم می‌کند.-به عنوان مثال : ما می‌توانیم فایل‌های استاتیک مثل تصاویر، فایل‌های CSS، و ... را در S3 ذخیره کرده و از آنها در برنامه‌های وب خود استفاده کنیم.3) Lambda- مفهوم Lambda : یک سرویس کاملاً مدیریت شده است که اجرای کدهای برنامه را بدون نگرانی از مدیریت سرور فراهم می‌کند.- مثال : ما می‌توانیم توابع کوچکی را برای پاسخ به رویدادهای مختلف (مانند بارگیری تصاویر) نوشته و آنها را در Lambda اجرا کنیم.4) RDS (Relational Database Service)- مفهوم RDS : یک سرویس مدیریت پایگاه داده‌های رابطه‌ای است از دیتابیس‌هایی مانند MySQL، PostgreSQLو ...- مثال: اگر برنامه‌ی شما به یک پایگاه داده MySQL نیاز دارد، می‌توانید از RDS برای ایجاد و مدیریت پایگاه داده استفاده کنید.بطور کلی AWS به عنوان یک پلتفرم گسترده ابری، انواع متنوعی از سرویس‌ها و ابزارهای دیگر را نیز ارائه می‌دهد که به توسعه‌دهندگان کمک می‌کند تا برنامه‌های خود را اجرا و مدیریت کنند.مفهوم3 ) API-first Approach رویکرد API-first یک روش در معماری نرم‌افزار است که در آن توسعه برنامه با تمرکز بر روی طراحی و توسعه رابط‌های برنامه نویسی(API) شروع می‌شود . این رویکرد متمرکز برAPIها به عنوان یک عنصر اصلی برای ارتباط بین ماژول‌ها ، سیستم‌ها ، و حتی سرویس‌های مستقل است .مفهوم رویکرد API-first :1 . تمرکز برAPI :- در رویکرد API-first ، تمرکز اصلی از ابتدا بر روی طراحی و تعریف APIها قرار دارد . APIها به عنوان واسط های ارتباطی بین بخش‌های مختلف برنامه یا بین برنامه و خدمات خارجی مورد توجه قرار می‌گیرند.2 . استفاده از ابزارهای مستقل :- از ابتدا از ابزارهای مخصوص به طراحی API استفاده می‌شود، مانند Swagger یا OpenAPI که به توسعه‌دهندگان این امکان را می‌دهد تا APIها را به صورت مستقل از برنامه توسعه دهند و تست کنند.3 . ارتباط توسعه‌دهندگان و سرویس‌ها :- توسعه‌دهندگان را قادر می‌سازد تا بدون نیاز به پیش‌نیازهای برنامه ، از APIهایی که ایجاد کرده‌اند، برای ارتباط با سرویس‌ها یا تیم‌های دیگر استفاده کنند.مثال:فرض کنید شما یک تیم توسعه دارید که یک برنامه مدیریت وظایف تحت وب می‌سازد. با استفاده از رویکرد API-first ، شما از ابتدا به طراحی و تعریف APIها برای برنامه خود می‌پردازید، مثلاً:1) Task API- یکAPI برای ایجاد، ویرایش، حذف و دریافت وظایف مرتبط با برنامه‌ی مدیریت وظایف2) User API- یکAPI برای مدیریت کاربران از جمله ثبت‌نام، ورود به سیستم، ویرایش پروفایل و مدیریت دسترسی‌ها3) Notification API- یکAPI برای ارسال اعلان‌ها و اطلاعیه‌ها به کاربران برنامهبا این رویکرد، حتی قبل از شروع توسعه برنامه اصلی، تیم ما می‌تواند این APIها را تعریف کرده و مستندات کامل برای آنها ایجاد کند. سپس سایر اعضای تیم یا تیم‌های متفاوت می‌توانند با استفاده از این APIها، بخش‌های مختلف برنامه را به صورت مستقل از هم توسعه دهند. این اجازه می‌دهد تا تیم‌ها به صورت همزمان و مستقل از یکدیگر فعالیت کنند و در نهایت، APIها را به یکدیگر متصل کنند تا یک برنامه کامل شکل گیرد.مفهوم4) NoSQL Databasesدیتابیس‌هایNoSQL (Not Only SQL) یک نوع از دیتابیس‌ها هستند که برای ذخیره و بازیابی داده‌ها از مدل داده‌های مختلف از جمله اشیاءJSON یا XML و یا داده‌های کلانی که ساختار ثابتی ندارند، استفاده می‌کنند. این دیتابیس‌ها به دلیل مقیاس‌پذیری بالا، انعطاف پذیری و عملکرد بهتر در مقابل بار کاری‌های بزرگ جذابیت بالایی دارند. مثال: فرض کنید شما یک برنامه مدیریت کتابخانه آنلاین دارید. در یک دیتابیس SQL، شما ممکن است دو جدول برای کتب و نویسندگان ایجاد کنید و با استفاده از کلیدهای خارجی، این دو جدول را به یکدیگر مرتبط کنید.حالا با دیتابیسNoSQL، به عنوان مثالMongoDB ، می‌توانید اطلاعات را به صورت مستند در یک مجموعه (Collection) ذخیره کنید . برای مثال:کتاب:```json{"_id": "book123","title": "The Great Gatsby","author": {"name": "F. Scott Fitzgerald","birth_year": 1896,"nationality": "American"},"genre": "Fiction","publication_year": 1925}```در اینجا، هر کتاب به عنوان یک شیء JSON با ویژگی‌های مختلف نمایش داده شده است. داده‌ها بدون ساختار ثابت و با انعطاف پذیری بیشتری ذخیره شده‌اند. اطلاعات نویسنده نیز به صورت یک شیء دیگر درون شیء کتاب ذخیره شده است . این نمونه نشان از این می‌دهد که چگونه در دیتابیس NoSQL، مدل داده می‌تواند بسیار انعطاف پذیرتر باشد و می‌تواند به راحتی با تغییرات در نیازهای برنامه تطابق پیدا کند .مفهوم5) Serverless Architectureمعماری بدون سرور(Serverless Architecture) یک رویکرد در توسعه نرم‌افزار است که تمرکز اصلی طراحی و توسعه برنامه را از مدیریت سرورها و زیرساخت‌های زیرین آن کاسته و به توسعه‌دهندگان این امکان را می‌دهد تا برنامه‌های خود را بدون نگرانی از مدیریت سرور اجرا کنند. در این رویکرد، اجزای برنامه به صورت تابع‌ها (Functions) به نام "تابع‌های بدون سرور" اجرا می‌شوند و منابع مورد نیاز برای این توابع به صورت خودکار توسط سرویس ارائه دهنده برنامه (مانندAWS Lambda یا Azure Functions) مدیریت می‌شوند. مفهوم معماری بدون سرور شامل:1. تابع‌های بدون سرور:- در این رویکرد، توسعه‌دهندگان توابع کوچک و مستقلی را تعریف می‌کنند که عملیات خاصی را انجام می‌دهند. این توابع به صورت مستقل اجرا شده و نیازی به اجرای یک سرور یا زیرساخت پشتیبانی ندارند.2. پردازش رویدادها :- برنامه بدون سرور براساس رویدادها عمل می‌کند. هر تابع به واکنش به یک رویداد (مثل یک درخواستHTTP یا وقوع یک رویداد داخلی) اجرا می‌شود و پس از اجرا به سرعت توقف می‌یابد.3. مدیریت منابع توسط سرویس‌های ابری:- منابع مورد نیاز برای اجرای توابع (مانند پردازنده و حافظه) به صورت خودکار توسط سرویس ارائه دهنده برنامه (مانندAWS Lambda یا Azure Functions) مدیریت می‌شوند. این به توسعه‌دهندگان اجازه می‌دهد تا بدون نگرانی از مقیاس‌پذیری و مدیریت زیرساخت‌ها، به توسعه برنامه بپردازند.مثال: فرض کنید ما یک برنامه تحلیل گر تصویر آنلاین داریم که تصاویر را تحلیل کرده و اطلاعاتی مانند تعداد اشیاء موجود در تصویر، رنگ‌ها، یا ویژگی‌های دیگر را استخراج می‌کند. در معماری بدون سرور، می‌توانیم از توابع بدون سرور برای اجرای هر یک از این وظایف استفاده کنیم.1.تابع تحلیل تصویر:- ما یک تابع بدون سرور تعریف می‌کنیم که با دریافت تصویر، آن را تحلیل کرده و اطلاعات مورد نیاز را استخراج می‌کند.2. تابع تشخیص اشیاء:- یک تابع دیگر تعریف می‌کنیم که به عنوان ورودی تصویر را گرفته و اشیاء موجود در آن را تشخیص می‌دهد.3. تابع تجزیه و تحلیل رنگ:- یک تابع دیگر برای تجزیه و تحلیل رنگ‌های موجود در تصویر ایجاد می‌کنیم.این توابع به صورت مستقل اجرا می‌شوند و نیازی به مدیریت سرور یا منابع زیرین ندارند. هر تابع به واکنش به یک رویداد (مثل آپلود تصویر) اجرا شده و پس از اتمام کار به سرعت توقف می‌یابد. این مدل معماری به توسعه سریع و مدیریت آسان برنامه کمک می‌کند، زیرا مسائل مربوط به زیرساخت‌ها به عهده سرویس ارائه دهنده برنامه است.مفهوم 6) Domain Driven Designطراحی دامین محور (Domain-Driven Design یا DDD) یک رویکرد برای توسعه نرم‌افزار است که به توسعه‌دهندگان کمک می‌کند تا با تمرکز بر روی مفاهیم دامین یا حوزه کسب و کار مسئله‌ای خاص را مدل کنند و آن را به یک ساختار برنامه قابل فهم و قابل تغییر تبدیل کنند. این رویکرد توسط اریک اِوَنز (Eric Evans) معرفی شده است.این مفهوم در بردارنده موارد زیر است :تمرکز بر دامین : DDD تاکید دارد که برنامه نویسان و تیم‌ها باید با تمرکز بر روی دامین (حوزه کسب و کار) مسئله، مفاهیم و فرآیندهای کلان را درک کنند. این اطلاعات توسعه‌دهندگان را در طراحی مدل دامین تحت‌تاثیر مستقیم قرار می‌دهد.زبان یکپارچه : با توجه به تمرکز بر دامین، از توسعه‌دهندگان خواسته می‌شود که یک زبان یکپارچه برای توصیف مفاهیم دامین (زبان یکپارچه) ایجاد کنند. این زبان باید موجب فهم بهتر مفاهیم دامین توسط تمام اعضای تیم شود.مدل‌سازی محلی:DDD از مدل‌سازی محلی (Local Modeling) حمایت می‌کند، به این معنا که مدل دامین باید تا حد امکان در محدوده‌های یک حوزه خاص (مثل یک ماژول یا خدمت) اعمال شود، و در نقاط ارتباط با حوزه‌های دیگر، این مدل بازتاب‌های مناسب داشته باشد.یکپارچگی با کد : مدل دامین باید به صورت یکپارچه با کد توسعه داده شود، یعنی باید تا حد امکان در کد پیاده‌سازی شود و تفاوت بین مفاهیم دامین و کد به حداقل رسانده شود.مثال : فرض کنید ما یک برنامه مدیریت فروشگاه آنلاین داریم.1.تمرکز بر دامین : - در DDD، ما تمرکز خود را بر روی دامین یعنی "فروشگاه آنلاین" قرار می‌دهیم. مفاهیم اصلی شامل محصولات، سبد خرید، سفارشات، و مشتریان است.2. زبان یکپارچه: - با توجه به دامین، تیم تصمیم می‌گیرد از یک زبان یکپارچه برای توصیف مفاهیم استفاده کند. مثلاً به جای استفاده از اصطلاحات مبهم یا تکراری، از اصطلاحاتی مشابه "سفارش" یا "محصول" استفاده می‌کنیم.3. مدل‌سازی محلی: - ما به این توجه داریم که هر مدل دامین در یک حوزه مشخص (مثل محصولات، سبد خرید یا سفارشات) به کار گرفته شود و تفاوت‌های مدل‌سازی بین این حوزه‌ها حفظ شود.حالا، بیایید یک مثال ساده برای یک دامین فروشگاه آنلاین را بررسی کنیم:- مفهوم: محصولات - تعریف دامین : - محصولات، کالاها یا خدماتی هستند که در فروشگاه آنلاین به فروش می‌رسند. - تعریف زبانی: - به جای استفاده از اصطلاحات گنگ و غیر واضح، از اصطلاحات مشخص و مرتبط مانند "محصول" یا "کالا" استفاده می‌شود. - مدل‌سازی محلی : - اطلاعات خاص به محصولات، مثل نام، قیمت، و مشخصات فنی، در یک مدل محلی (مثل یک کلاس در کد) مدل می‌شوند.این مثال نشان می‌دهد که چگونه با تمرکز بر روی دامین، استفاده از یک زبان یکپارچه و مدل‌سازی محلی، مفاهیم دامین به یک ساختار برنامه قابل فهم تبدیل می‌شوند و توسعه‌دهندگان می‌توانند با تسهیل درک مفاهیم کسب و کار بهتر برنامه‌نویسی کنند.مفهوم 7 ) Hexagonal architectureمعماری هگزاگونال (Hexagonal Architecture) یک الگوی طراحی نرم‌افزار است که تاکید دارد برنامه نویسی باید بر اساس مفاهیم کسب و کار انجام شود و وابستگی به جزئیات فنی خاص (مانند دیتابیس یا فریم‌ورک‌های ویژه) باید حداقل باشد. این الگو به نام هگزاگونال به دلیل شباهت ساختار آن با یک شکل هگزاگون (شش‌ضلعی) نامگذاری شده است.ویژگی های معماری هگزاگونال:1.یکپارچگی با دامین:- الگوی هگزاگونال تأکید دارد که برنامه باید به صورت مرکزی بر اساس مفاهیم دامین (حوزه کسب و کار) طراحی شود. این به این معناست که توسعه‌دهندگان باید به اولویت بالایی به مسائل کسب و کار توجه کنند و در تصمیمات فنی خود، این مسائل را به چالش نکشند.2. ایزوله‌سازی لایه‌ها:- در معماری هگزاگونال، لایه‌های مختلف برنامه به صورت هگزاگونال ایزوله می‌شوند. به این معنا که هر لایه (مانند لایه حوزه دامین، لایه ورودی، و لایه خروجی) مستقل از دیگر لایه‌ها عمل می‌کند و وابستگی به جزئیات دیگر لایه‌ها حداقل است.3. پورتها و آدابتور ها :- در این معماری، از مفهوم پورتها (Ports) و آداپتورها (Adapters) استفاده می‌شود. پورتها نقاط ارتباط با لایه‌های خارجی هستند که تعریف می‌کنند چگونه اطلاعات به داخل و خارج از برنامه جاری جریان دارند. آداپتورها هم مسئولیت ترجمه داده‌ها و وابستگی به جزئیات لایه‌های خارجی را بر عهده دارند.بیایید یک مثال ساده از یک سرویس ثبت نام در یک برنامه وب با استفاده از معماری هگزاگونال بررسی کنیم:1.لایه حوزه دامین:- در این لایه، مفاهیم کسب و کار مانند "کاربر" و "ثبت نام" مدل می‌شوند. مثلاً یک مدل User با ویژگی‌هایی مانند نام، ایمیل و رمزعبور ایجاد می‌شود.2. لایه ورودی (پورت و آداپتور):- یک پورت ورودی برای سرویس ثبت نام تعریف می‌شود که مسئول دریافت درخواست‌های ثبت نام از کاربران است. یک آداپتور به عنوان ترجمه‌کننده بین پورت ورودی و لایه حوزه دامین عمل می‌کند .3. لایه خروجی (پورت و آداپتور) :- یک پورت خروجی برای ثبت نام تعریف می‌شود که مسئول ارسال اطلاعات ثبت نام به لایه خروجی (مثلاً ذخیره در دیتابیس) است. یک آداپتور به عنوان ترجمه‌کننده بین پورت خروجی و لایه حوزه دامین عمل می‌کند.این ساختار هگزاگونال این اطمینان را می‌دهد که لایه حوزه دامین (که مهمترین بخش برنامه است) از جزئیات فنی دیگر لایه‌ها جدا مانده و تغییرات در لایه‌های دیگر تأثیر کمی بر روی لایه حوزه دارد. این اصول به توسعه قابل تست و نگهداری، افزایش انعطاف‌پذیری و امکان تست و ادغام آسان تر کمک می‌کند.مفهوم 8 ) Event SourcingEvent Sourcing یک الگوی طراحی در معماری نرم‌افزار است که در آن وضعیت فعلی یک سیستم با ذخیره و مدیریت رخدادها (Events) تعیین می‌شود. به جای ذخیره وضعیت فعلی، تمام تغییرات و رخدادها که باعث تغییر وضعیت شده‌اند، به صورت یک سری رخداد ذخیره می‌شوند. این الگو به تاریخچه تغییرات در وضعیت سیستم توجه می‌کند و این امکان را فراهم می‌کند که وضعیت سیستم را به هر زمانی در گذشته بازگردانی کنیماین الگو شامل :.رخدادها:- در Event Sourcing، تمام تغییرات حالت یک سیستم به عنوان رخدادها ذخیره می‌شوند. هر رخداد نمایانگر یک تغییر در وضعیت سیستم در زمان خاصی است.2.ذخیره سازی رخدادها:- رخدادها در یک دیتابیس یا سیستم ذخیره سازی رخداد (Event Store) ذخیره می‌شوند. این دیتابیس به جای ذخیره وضعیت فعلی، تمام تغییراتی که به وضعیت منجر شده‌اند را ذخیره می‌کند.3. بازگردانی وضعیت:- برای بازگردانی وضعیت فعلی سیستم، همه رخدادها به ترتیب زمانی مورد استفاده قرار می‌گیرند. با اجرای همه رخدادها از ابتدا تا زمان مورد نظر، وضعیت فعلی به دست می‌آیدبرای درک بهتر Event Sourcing، فرض کنید شما یک سیستم سفارشات آنلاین دارید:خب در این صورت :1. رخدادها :- رخدادهای ما می‌توانند شامل "سفارش ثبت شده"، "پرداخت انجام شده"، "ارسال شده" و غیره باشند. هرکدام از این رخدادها یک تغییر در وضعیت سفارش نمایانگر می‌شوند.2. ذخیره سازی رخدادها:- وقتی یک سفارش ثبت می‌شود، یک رخداد "سفارش ثبت شده" در دیتابیس رخدادها ذخیره می‌شود. هر رخداد شامل اطلاعات لازم برای بازسازی وضعیت در آینده است.3. بازگردانی وضعیت:- اگر بخواهیم وضعیت فعلی یک سفارش را بدانیم، تمام رخدادها از ابتدا تا کنون به ترتیب زمانی اجرا می‌شوند. مثلاً ابتدا رخداد "سفارش ثبت شده" اجرا شده، سپس رخداد "پرداخت انجام شده" و غیره.این الگو به ما این امکان را می‌دهد که به راحتی تاریخچه تغییرات یک موجودیت را مدیریت کرده و وضعیت فعلی سیستم را در هر زمانی بازسازی کنیم. همچنین با استفاده از این الگو، می‌توانیم آنالیز تاریخچه را انجام داده و الگوهای تغییرات را بررسی کرد.مفهوم 9 ) Low code platformsپلتفرم‌های "Low-Code" یا "Low-Code Development Platforms" ابزارهایی هستند که توسعه نرم‌افزار را برای توسعه‌دهندگان سهولت بخشیده و نیاز به توانمندی‌های برنامه‌نویسی عالی را کاهش می‌دهند. این ابزارها از یک رابط گرافیکی و کم‌کد (Low-Code) برای طراحی و توسعه برنامه‌ها استفاده می‌کنند و به توسعه‌دهندگان امکان می‌دهند تا بدون نیاز به نوشتن کد برنامه‌های پیچیده‌ای ایجاد کنند.از ویژگی های این ابزار میتوان به موارد زیر اشاره کرد:1. رابط گرافیکی:- این پلتفرم‌ها یک رابط گرافیکی فراهم می‌کنند که توسعه‌دهندگان می‌توانند از طریق کشیدن و رها کردن المان‌ها، تنظیم تنظیمات و ایجاد اتصالات، بدون نیاز به نوشتن کد، برنامه‌های خود را طراحی کنند.2. کم‌کد بودن(Low-Code):- علاوه بر رابط گرافیکی، این پلتفرم‌ها اغلب ابزارها و کامپوننت‌های آماده برای افزودن به برنامه‌ها فراهم می‌کنند. این کدها به صورت خودکار تولید می‌شوند یا اینکه کمک به توسعه‌دهندگان می‌کنند تا کد کمتری بنویسند.3. تسهیل در توسعه سریع:- از طریق استفاده از Low-Code Platforms، توسعه‌دهندگان می‌توانند به سرعت برنامه‌های کاربردی را ایجاد کنند. این امکان باعث می‌شود تا تحویل پروژه‌ها به سرعت انجام شود و نیاز به زمان طولانی برای توسعه نرم‌افزار کاهش یابد4. انعطاف‌پذیری:- برخی از پلتفرم‌های Low-Code امکان سفارشی‌سازی و توسعه داده شده توسط کد نیز فراهم می‌کنند. این به توسعه‌دهندگان حرفه‌ای امکان می‌دهد که از قابلیت‌های Low-Code برای ایجاد بخش‌های سفارشی و پیچیده‌تر برنامه استفاده کنند.به طور کلی، Low-Code Platforms به توسعه‌دهندگان با سطح مهارت مختلف این امکان را می‌دهند که به سرعت و با ابزارهای گرافیکی، برنامه‌های کاربردی را ایجاد کنند و همچنین از امکانات سفارشی‌سازی برخوردار شوند.مفهوم 10 ) Business Process Management Systems (BPMS)یک دسته از سیستم‌های مدیریت فرآیند کسب و کار(Business Process Management Systems) هستند که برای بهبود و مدیریت فرآیندهای کسب و کار در یک سازمان به کار می‌روند. این سیستم‌ها از ابزارها، تکنولوژی‌ها و ساختارهای نرم‌افزاری تشکیل شده‌اند که اجازه می‌دهند فرآیندهای کاری را مدیریت، اندازه‌گیری، بهینه‌سازی و پیگیری کنند. در ادامه، به توضیح مفهوم BPMS با یک مثال خواهیم پرداخت.1. مدیریت فرآیند کسب و کار:- این سیستم ها (BPMS) به سازمان‌ها کمک می‌کند تا فرآیندهای کاری خود را بهبود بخشند. این شامل تعیین، طراحی، اجرا، پیگیری و بهینه‌سازی فرآیندها می‌شود.2.تجزیه و تحلیل فرآیند:- این سیستم ها (BPMS) امکان تجزیه و تحلیل دقیق و کامل فرآیندهای کسب و کار را فراهم می‌کند. این به مدیران اجازه می‌دهد تا دقیقترین اطلاعات را در مورد عملکرد و بهره‌وری فرآیندها بدست آورند.3. اجرای خودکار فرآیندها:- این سیستم ها (BPMS) امکان اجرای خودکار و اتوماتیک فرآیندها را فراهم می‌کند. این به معنای این است که وظایف، گام‌ها و اطلاعات بصورت خودکار بین افراد و سیستم‌ها منتقل می‌شوند.4. پایش و پیگیری:- این سیستم ها (BPMS) به کمک ابزارها و داشبوردهای مدیریتی، امکان پایش و پیگیری فرآیندها را فراهم می‌کند. این به مدیران این امکان را می‌دهد تا به سرعت و به طور دقیق وضعیت هر فرآیند را مشاهده کنند.به عنوان مثال : فرض کنید که یک شرکت تولیدی ، فرآیند تولید و توزیع محصولات خود را مدیریت می‌کند. این شرکت از یک BPMS برای بهبود و اتمام بهتر این فرآیند استفاده می‌کند:1. مدیریت فرآیند:- این سیستم ها (BPMS) به این شرکت کمک می‌کند تا فرآیندهای تولید، انبار، حمل و نقل، و توزیع محصولات خود را بهینه کند .2. تجزیه و تحلیل فرآیند:- مدیران از BPMS استفاده می‌کنند تا به تحلیل دقیقی از زیرساخت‌ها و گام‌های فرآیند تولید بپردازند و بهبودهای لازم را اعمال کنند3. اجرای خودکار فرآیندها:- این سیستم ها (BPMS) به این شرکت این امکان را می‌دهد که بخش‌هایی از فرآیند تولید را به صورت خودکار اجرا کرده و اطلاعات بین افراد و سیستم‌ها منتقل کند.4. پایش و پیگیری:- با استفاده از داشبوردها و گزارش‌های BPMS، مدیران به سرعت می‌توانند وضعیت کلی فرآیندها را پایش و پیگیری کنند و در مورد هر گام مشکلات را حل کنند.در نتیجه، BPMS به شرکت‌ها این امکان را می‌دهد تا فرآیندهای کسب و کار خود را به بهترین شکل مدیریت و بهبود دهند.مفهوم 11 ) Message Queue (such as Kafka and RabbitMQ)صف پیام (Message Queue) یک مفهوم مهم در معماری نرم‌افزار است که برای ارتباط بین اجزای مختلف یک سیستم و ارسال و دریافت پیام‌ها بین آنها استفاده می‌شود. این سیستم‌ها به اجزاء مختلف یک برنامه امکان ارسال و دریافت پیام‌ها با قابلیت تاخیر و ذخیره‌سازی اطلاعات فراهم می‌کنند. دو نمونه مشهور از صف‌های پیام، Apache Kafka و RabbitMQ هستند. در ادامه با مفهوم صف پیام و نحوه استفاده از آن با یک مثال آشنا می‌شویم . صف پیام دارای ویژگی های زیر است :1. ارتباط ناهمزمان:- صف پیام به اجزاء مختلف یک سیستم این امکان را می‌دهد که پیام‌ها را به صورت ناهمزمان ارسال و دریافت کنند. این به اجزا این امکان را می‌دهد که با هم تعامل کنند حتی اگر یکی از آنها در دسترس نباشد یا تاخیر داشته باشد.2. کاهش وابستگی:- با استفاده از صف پیام، اجزاء مختلف می‌توانند با کاهش وابستگی به همدیگر، به صورت مستقل کار کنند. هر اجزا تنها باید توانایی ارسال و دریافت پیام را داشته باشد.3. تاخیر و مدیریت بار:- صف پیام به اجزاء این امکان را می‌دهد که پیام‌ها را برای مصرف آینده ذخیره کنند و همچنین تاخیرهای مدیریتی را کنترل کنند. این امکان می‌تواند برای مدیریت بار (Load Balancing) نیز مفید باشد.به عنوان مثال فرض کنید یک سیستم تجارت الکترونیک دارید که از صف پیام برای مدیریت سفارشات استفاده می‌کندکه در این صورت :1.هنگام ثبت سفارشات:- هر زمانی که یک مشتری سفارشی ثبت می‌کند، یک پیام درون یک صف پیام قرار می‌گیرد. این پیام می‌تواند شامل اطلاعات سفارش مانند آیتم‌های خریداری شده، مشخصات مشتری و تاریخ ثبت سفارش باشد.2. برای پردازش سفارش:- یک سرویس مستقل برای پردازش سفارشات این صف را گوش می‌دهد. این سرویس هر پیام را از صف دریافت کرده، سفارش را پردازش کرده و عملیات مربوطه مانند تایید سفارش و به‌روزرسانی موجودی را انجام می‌دهد.3. اطلاع رسانی:- سیستم می‌تواند از یک پیام دیگر در صف برای اطلاع رسانی به مشتریان استفاده کند. مثلاً پیامی که به مشتری اطلاع دهد که سفارششان تأیید شده و آماده ارسال است.با استفاده از صف پیام، این سیستم تجارت الکترونیک به سرعت و به شکل ناهمزمان و از طریق اجزاء مختلفی مانند سرویس‌ها و ماژول‌های مستقل خود، سفارشات را مدیریت می‌کند. این امکان به سیستم این اطمینان را می‌دهد که حتی در مواقع ترافیک بالا یا تغییرات ناگهانی، اطلاعات به درستی و به‌موقع پردازش می‌شوند.مفهوم 12 ) Container orchestration (such as Kubernetes)این مفهوم(Container Orchestration) برای مدیریت و اجرای برنامه‌های قابل حمل (Containerized) که با استفاده از تکنولوژی هایی مانند Docker ایجاد شده‌اند، استفاده می‌شود. این سیستم‌ها به اجرای و مدیریت چندین کانتینر در یک سیستم متناهی کمک می‌کنند و وظایفی نظیر ایجاد، مقیاس‌پذیری، مانیتورینگ، و اجرای خدمات در محیط‌های ابری و محلی را انجام می‌دهند. یکی از معروف‌ترین سیستم‌های ، Kubernetes ContainerOrchestration است.از مشخصه های این سازوکار میتوان به موارد زیر اشاره کرد :1. مدیریت و اجرا:- این سیستم‌ها برای مدیریت و اجرای تعداد زیادی از کانتینرها در یک یا چند سرور به کار می‌رود. این امکان را فراهم می‌کند تا برنامه‌های ارتقاپذیر و قابل حمل را بر روی زیرساخت‌های مختلف اجرا کنیم.2. مقیاس‌پذیری:- این سیستم‌ها به اجرا و مقیاس‌پذیری برنامه‌ها بر اساس نیازهای ترافیک و بار کمک می‌کند. به این ترتیب، می‌توانیم به راحتی تعداد کانتینرها را افزایش یا کاهش دهیم.3. مانیتورینگ:- این سیستم‌ها امکان مانیتورینگ برنامه‌ها و کانتینرها را فراهم می‌کنند. اطلاعاتی مانند استفاده از منابع، لاگ‌ها، و وضعیت سلامتی سرویس‌ها قابل دسترسی است.خودکارسازی: Container Orchestration اجزای مختلف مانند ایجاد، به‌روزرسانی، و مقیاس‌پذیری برنامه‌ها را به صورت خودکار انجام می‌دهد و این امکان را به توسعه‌دهندگان می‌دهد تا بر روی توسعه برنامه متمرکز شوند تا نگرانی‌های مدیریتی نباشند.مثال:حال برای درک بهتر این ویژگی ها به مثال زیر دقت کنیم :فرض کنید یک برنامه وب داریم که با استفاده از کانتینرهای Docker پیاده‌سازی شده است و به وسیله Kubernetes در یک محیط ابری مدیریت می‌شود:1. در مرحله ایجاد:- با استفاده از Kubernetes، می‌توانیم کانتینرها را به صورت خودکار ایجاد و مدیریت کنیم. به عنوان مثال، با یک تنظیمات YAML، می‌توانیم یک Deployment ایجاد کنیم که شامل تعدادی از کانتینرهای برنامه شما باشد.2.مقیاس‌پذیری:- در زمان افزایش ترافیک، Kubernetes می‌تواند به صورت خودکار تعداد کانتینرها را افزایش دهد تا با نیازهای بار مطابقت داشته باشد. این کار به معنای مقیاس‌پذیری افقی (Horizontal Scaling) است3. مانیتورینگ:- و Kubernetes اطلاعاتی از نظر مانیتورینگ فراهم می‌کند. این اطلاعات می‌توانند شامل مصرف حافظه و پردازنده، لاگ‌ها، و وضعیت پروازی سرویس‌ها باشند.4. خودکارسازی:- مثلاً اگر یک نسخه جدید از برنامه منتشر شود، Kubernetes می‌تواند به صورت خودکار تغییرات را اعمال کند و سرویس‌ها را به نسخه جدید بروزرسانی کند.مفهوم 13 ) Log Management Tools (such as ELK)ابزارهای مدیریت لاگ (Log Management) برای جمع‌آوری، ذخیره، جستجو و تحلیل لاگ‌های تولید شده توسط برنامه‌ها و سیستم‌ها به کار می‌روند. این ابزارها به توسعه‌دهندگان و مدیران سیستم این امکان را می‌دهند تا اطلاعات لازم برای رفع مشکلات، نظارت بر عملکرد، و تحلیل رفتار سیستم را بدست آورند. یکی از مشهورترین ابزارهای مدیریت لاگ، مجموعه ELK (Elasticsearch, Logstash, Kibana) است. در ادامه با مفهوم ابزارهای مدیریت لاگ و نحوه استفاده از ELK Stack آشنا می‌شویم.از جمله ویژگی های این ابزار میتوان به موارد زیر اشاره کرد:1. جمع‌آوری لاگ‌ها:- این ابزارها برای جمع‌آوری لاگ‌های تولید شده توسط برنامه‌ها و سیستم‌ها به کار می‌روند. لاگ‌ها می‌توانند شامل اطلاعات عیب‌یابی، عملکرد، رویدادها و اطلاعات مربوط به امنیت باشند.2. ذخیره لاگ‌ها:- لاگ‌ها به صورت موقت یا دائمی در یک مخزن (مثل پایگاه داده یا فایل) ذخیره می‌شوند. این امکان را فراهم می‌کند تا اطلاعات لاگ به مدت مشخصی نگهداری شوند و قابلیت جستجو و بازیابی داشته باشند.3. تحلیل لاگ‌ها:- این ابزارها به تحلیل لاگ‌ها برای استخراج اطلاعات مفید کمک می‌کنند. مثلاً جستجوی خطاها، تحلیل عملکرد سیستم، شناسایی الگوها و تشخیص تهدیدات امنیتی.4. نمایش گرافیکی- برخی از ابزارهای مدیریت لاگ، امکان نمایش گرافیکی اطلاعات لاگ را ارائه می‌دهند. این امکان باعث می‌شود تا تحلیل لاگ‌ها و نظارت بر وضعیت سیستم به وسیله داشبوردها و گزارش‌های گرافیکی انجام شود.حسب مثال فرض کنید که شما یک وبسایت تجاری دارید که به کمک ELK Stack برای مدیریت لاگ‌ها از این ابزارها بهره‌مند هستید:برای مثال فرض کنیم که ما یک وبسایت تجاری داریم که به کمک ELK Stack برای مدیریت لاگ‌ها از این ابزارها بهره‌مند هستیم:1. جمع‌آوری لاگ‌ها با Logstash:- وبسایت ما هر زمان که یک کاربر خریدی انجام می‌دهد یا با صفحات وبسایت تعامل دارد، لاگ‌هایی تولید می‌کند. از طریق Logstash، این لاگ‌ها جمع‌آوری شده و به Elasticsearch ارسال می‌شوند.2.ذخیره لاگ‌ها در Elasticsearch:- به عنوان مخزن داده(Elasticsearch) برای لاگ‌ها عمل می‌کند. به عنوان مثال، اطلاعاتی مانند زمان خرید، محصولات خریداری شده، زمان ورود به سایت، و غیره در Elasticsearch ذخیره می‌شود .3. تحلیل لاگ‌ها با Kibana:- با استفاده از Kibana، می‌توانیم به راحتی لاگ‌ها را تحلیل کنیم. مثلاً می‌توانید تعداد خریدها در یک بازه زمانی مشخص را بررسی کرده، الگوهای رفتاری کاربران را تجزیه و تحلیل کنیم و یا لاگ‌های خطا را بررسی کنیم.4. نمایش گرافیکی با داشبورد Kibana:- از طریق داشبوردها و گزارش‌های گرافیکی Kibana، می‌توانیم به راحتی وضعیت و عملکرد وبسایت خود را نظارت کنیم. مثلاً ممکن است یک نمودار نشان دهد که در زمان‌های خاصی از روز ترافیک وبسایت ما افزایش یافته است.مفهوم 14 ) Monitoring tools (such as Prometheus)ابزارهای نظارت (Monitoring Tools) نقش مهمی در معماری نرم‌افزار ایفا می‌کنند و برای نظارت و اندازه‌گیری عملکرد سیستم‌ها و برنامه‌ها به کار می‌روند. این ابزارها اطلاعاتی از نظر ترافیک، منابع سخت‌افزاری، وضعیت سرویس‌ها، و سایر موارد را جمع‌آوری کرده و به توسعه‌دهندگان و مدیران سیستم کمک می‌کنند تا وضعیت سیستم را نظارت کنند و در صورت نیاز بهبودهای لازم را اعمال کنند. یکی از ابزارهای معروف نظارت، Prometheus است.ویژگی ها :1.جمع‌آوری داده‌ها:- این ابزارها برای جمع‌آوری داده‌های مختلفی از سطح سیستم، برنامه یا شبکه استفاده می‌شوند. این داده‌ها ممکن است شامل اطلاعاتی از نظر عملکرد، مصرف منابع، خطاها، وضعیت سرویس‌ها و غیره باشند.2. ذخیره داده‌ها:- داده‌های جمع‌آوری شده در یک مخزن مانند دیتابیس یا ذخیره سریع (Time-Series Database) ذخیره می‌شوند. این امکان به تحلیل دقیق تر و نگهداری اطلاعات برای مدت زمان طولانی کمک می‌کند.3. تحلیل و نمایش:- ابزارهای نظارت به تحلیل و نمایش داده‌ها با استفاده از گزارش‌ها، نمودارها، و داشبوردها می‌پردازند. این نمایش‌ها به مدیران سیستم و توسعه‌دهندگان کمک می‌کنند تا به سرعت و به‌طور گسترده وضعیت سیستم را مشاهده کنند.4. هشداردهی:- ابزارهای نظارت معمولاً قابلیت هشداردهی دارند تا در صورت اتفاقات غیرمنتظره یا کاهش عملکرد، اطلاعات هشدار را به توسعه‌دهندگان یا مدیران ارسال کنند.مثال با Prometheus:فرض کنید یک برنامه وب داریم که با استفاده از Prometheus برای نظارت استفاده می‌کنیم:1.جمع‌آوری داده‌ها:- با Prometheus به طور مداوم از سرویس‌ها و برنامه‌های مختلف داده‌ها را جمع‌آوری می‌کند. به عنوان مثال، تعداد درخواست‌ها به وبسایت، زمان پاسخ سرویس‌ها، وضعیت پایگاه داده و ..2.ذخیره داده‌ها :- این داده‌ها در Prometheus ذخیره می‌شوند و از یک مدیر داده‌های زمان‌سری برای نگهداری این اطلاعات استفاده می‌کند.3. تحلیل و نمایش با Grafana:- برای تحلیل داده‌ها و نمایش گرافیکی آنها، Prometheus ممکن است با ابزارهایی مانند Grafana همکاری کند. این امکان به توسعه‌دهندگان و مدیران اجازه می‌دهد تا وضعیت سیستم را از نظر گسترده‌تر و گرافیکی‌تر مشاهده کنند.4.هشداردهی:- در صورتی که مقادیر یا وضعیتی از آستانه مشخص فراتر بروند، Prometheus می‌تواند هشدارها ایجاد کرده و به توسعه‌دهندگان یا مدیران ارسال کند.مفهوم 15 ) Static Code Analysis (such as SonarQube)تجزیه و تحلیل کد استاتیک (Static Code Analysis) یک فرایند اتوماتیک است که به منظور ارزیابی کیفیت کد منبع برنامه استفاده می‌شود. این فرایند به تحلیل سورس کد بدون اجرای آن می‌پردازد و به توسعه‌دهندگان کمک می‌کند تا مشکلات پتانسیل و بهینه‌سازی‌های کد را قبل از اجرا تشخیص دهند. یکی از ابزارهای شناخته شده برای تجزیه و تحلیل کد استاتیک، SonarQube است.این فرآیند شامل : 1 . تحلیل کیفیت کد:- تجزیه و تحلیل کد استاتیک به بررسی رفتارها، الگوها، و ساختارهای کد می‌پردازد. این ابزارها اشکالاتی همچون کدهای تکراری، تداخل‌ها، نقض‌های استانداردهای کدنویسی، و غیره را شناسایی می‌کنند.2. شناسایی مشکلات امنیتی:- تجزیه و تحلیل کد استاتیک می‌تواند به شناسایی مشکلات امنیتی مانند نقاط ضعف امنیتی، نقض‌های OWASP، یا آسیب‌پذیری‌های ممکن کمک کند.3. بهبود قابلیت خوانایی:- این ابزارها به بهبود قابلیت خوانایی کد کمک می‌کنند. اطلاعاتی نظیر نظافت کد، نام‌گذاری صحیح متغیرها، و توجیه‌نامه‌های کد ممکن است از طریق این فرایند بهبود یابد.4. آزمون عملکرد:- تجزیه و تحلیل کد استاتیک می‌تواند به بهبود عملکرد برنامه کمک کند. از طریق شناسایی نقاط کد زمان‌بر یا عملکردهای ناکارآمد، توسعه‌دهندگان می‌توانند بهینه‌سازی‌های لازم را اعمال کنند. مثال با SonarQube:1. مرحله شناسایی کدهای تکراری:- با SonarQube می‌توان کدهای تکراری را شناسایی کرده و اطلاعاتی در مورد تعداد تکرارها و موقعیت آنها فراهم کرد. این کار باعث کاهش پیچیدگی و افزایش خوانایی کد می‌شود.2. بررسی استانداردهای کدنویسی:- از آنجا که SonarQube از استانداردهای کدنویسی معروف مانند Java Code Conventions یا Python PEP8 استفاده می‌کند و مشکلاتی که با این استانداردها در تضاد هستند را گزارش می‌دهد.3.شناسایی آسیب‌پذیری‌های امنیتی:- این ابزار می‌تواند آسیب‌پذیری‌های امنیتی مانند استفاده از توابع خطرناک یا مشکلات امنیتی مرتبط با حافظه را شناسایی کرده و اطلاعات مربوط به آنها را ارائه دهد.4.تحلیل پیچیدگی کد:- با SonarQube می‌توان پیچیدگی‌های کد را با استفاده از معیارهایی نظیر Cyclomatic Complexity اندازه‌گیری و به توسعه‌دهندگان کمک کرد تا کدهای پیچیده را بهینه‌سازی کنند.در نتیجه با استفاده از SonarQube، توسعه‌دهندگان قادر به اجرای تحلیل کامل و جامع بر روی کد منبع خود هستند تا کیفیت و قابلیت نگهداری کد را بهبود ببخشند.محمد گنجیمحمد گنجیTue, 21 Nov 2023 00:36:26 +0330https://virgool.ir/@m_14355741/خلاصه-مروری-از-فصل-های-15-تا-29-کتاب-معماری-تمیز-suqjxnbv9dsyمعماری به طراحی یک سیستم اشاره می کند ، با هدف ایجاد ساختاری که الزامات خاصی را برآورده می کند در حالی که عواملی مانند عملکرد ، حفظ قابلیت ، مقیاس پذیری و قابلیت استفاده را نیز در نظر می گیرد . در مهندسی نرم افزار، معماری به طراحی سیستم نرم افزار از جمله اجزای آن، رابط ها و روابط بین آنها اشاره دارد . یک طراحی خوب در معماری نرم افزار می تواند تفاوت قابل توجهی در کیفیت ، قابلیت نگهداری و مقیاس پذیری سیستم نرم افزار ایجاد کند . معماری به طراحی یک سیستم از جمله ساختار، رفتار و روابط بین اجزای آن اشاره دارد . در توسعه نرم افزار معماری ، طراحی سطح بالایی از نرم افزار را توصیف می کند از جمله چگونگی سازماندهی آن، اجزای اصلی که سیستم را تشکیل می دهند و اینکه چگونه این اجزای با یکدیگر ارتباط برقرار می کنند . هدف از معماری نرم افزار ایجاد یک سیستم است که به آسانی قابلیت حفظ، مقیاس پذیری و سازگاری با تغییر الزامات را دارا باشد . کتاب معماری تمیز راهنمای ساخت سیستم های نرم افزاری ای است که برای حفظ ، گسترش و تغییر آسان هستند . فصل استقلال ، درباره اهمیت ایجاد اجزای مستقل در یک سیستم نرم افزاری بحث می کند . به گفته مارتین، اجزای مستقل کسانی هستند که می توانند بدون تاثیر بر رفتار اجزای دیگر تغییر کنند . او استدلال می کند که ایجاد اجزای مستقل برای ساخت سیستم های نرم افزاری که انعطاف پذیر و آسان برای حفظ هستند ضروری است. در فصل استقلال، مارتین چندین استراتژی برای ایجاد اجزای مستقل، از جمله استفاده از رابط ها، انتزاع ها و جدایی نگرانی ها را مورد بحث قرار می دهد. او همچنین در مورد اهمیت اجتناب از اتصال سخت بین اجزا بحث می کند و بر نیاز به ایجاد سیستم های متصل به هم تاکید می کند.در مبحث خط مرزی بر اهمیت ترسیم یک خط روشن بین دو سیستم مختلف در تلاش برای حفظ یکپارچگی هر سیستم تمرکز داریم . این قسمت با معرفی مفهوم خط مرزی آغاز می شود که یک خط نظری است که دو سیستم مختلف را جدا می کند . خط مرزی به عنوان یک مرز عمل می کند که مانع از دخالت یک سیستم در سیستم دیگر می شود . این قسمت توضیح می دهد که وقتی سیستم ها به وضوح از هم جدا نمی شوند ، می تواند منجر به تعدادی از مسائل ، از جمله افزایش پیچیدگی ، کاهش قابلیت نگهداری و کاهش عملکرد شود . با ترسیم خط مرزی شفاف بین دو سیستم ، مدیریت و نگهداری هر سیستم به طور مستقل آسان تر می شود . این قسمت همچنین در مورد اهمیت استفاده از رابط های مناسب برای تسهیل ارتباط بین دو سیستم بحث می کند . استفاده از رابط های روشن و به خوبی تعریف شده می تواند اطمینان حاصل کند که هر سیستم به طور مستقل عمل می کند و با دیگری تداخل ندارد . به طور کلی، معماری تمیز اهمیت طراحی خط مرزی روشن بین دو سیستم مختلف را برای حفظ یکپارچگی هر سیستم برجسته می کند . با استفاده از رابط های مناسب و مرزهای روشن ، مدیریت و حفظ هر سیستم به طور مستقل آسان تر می شود. در ادامه به اهمیت تعریف مرزهای روشن بین اجزای مختلف یک سیستم نرم افزار پرداخته میشود . نویسنده استدلال می کند که بدون مرزهای روشن ، سیستم های نرم افزاری برای حفظ ، گسترش و تغییر در طول زمان دشوار می شوند . و از مفهوم "Dependency Inversion" به عنوان راهی برای ایجاد مرزهای روشن بین اجزا بحث می کند . عدم وابستگی شامل تجزیه و تحلیل وابستگی بین دو جزء است . به طوری که اجزایی که به احتمال زیاد تغییر می کنند به اجزایی که کمتر احتمال دارد تغییر کند ، وابسته نیستند . این به کاهش تاثیر تغییرات در یک جزء بر اجزای دیگر در سیستم کمک می کند .درگام بعدی بر سیاست و سطح طراحی نرم افزار تمرکز داریم . کتاب بر اهمیت در نظر گرفتن جنبه های سیاسی طراحی نرم افزار و چگونگی تاثیر آن بر معماری کلی سیستم تأکید می کند . استدلال میشود که جنبه های سیاسی طراحی نرم افزار به اندازه جنبه های فنی مهم است و نباید نادیده گرفته شود . همچنین در مورد سطوح مختلف طراحی نرم افزار، از جمله لایه نرم افزار، لایه زیرساخت و لایه پایه بحث میشود . نویسنده استدلال می کند که هر لایه باید با مجموعه ای از اصول و مرزهای خود ، بر اساس نیازهای خاص سیستم طراحی شود . مارتین بر اهمیت نگه داشتن هر لایه جداگانه و مستقل تاکید می کند تا اطمینان حاصل شود که تغییرات در یک لایه بر لایه های دیگر تأثیر نمی گذارد . در طول فصل ، نمونه هایی از چگونگی اعمال این اصول به سناریوهای طراحی نرم افزار در دنیای واقعی ارائه شده است . بحث اصلی در مورد اهمیت استفاده از ابزار و فن آوری های مناسب برای هر لایه و چگونگی اطمینان از اینکه لایه های مختلف به صورت یکپارچه کار می کنند ، است . به طور کلی ، این بخش از کتاب معماری تمیز نقش یک راهنمای جامع را برای جنبه های سیاسی و سطح طراحی نرم افزار فراهم می کند.در بخش قانون کسب و کار ، ما در مورد چگونگی اطمینان از اینکه نرم افزار مطابق با الزامات دامنه کسب و کار است ، بحث می کنیم . دامنه کسب و کار مجموعه ای از قوانین و محدودیت هایی است که رفتار نرم افزار را اداره می کند . تاکید شده است که دامنه کسب و کار از دامنه نرم افزار جدا است . دامنه نرم افزار مجموعه ای از قوانین و محدودیت هایی است که رفتار خود نرم افزار را اداره می کند . ضروری است که این دو دامنه را جداگانه نگه داریم تا اطمینان حاصل شود که نرم افزار مطابق با الزامات دامنه کسب و کار است . برای دستیابی به این جدایی ، استفاده از زمینه های محدود را پیشنهاد میشود . یک زمینه محدود مجموعه ای از کلاس ها است که یک واژگان مشترک را به اشتراک می گذارند و مسئول جنبه خاصی از دامنه کسب و کار هستند . هر زمینه محدود باید مخزن و نقشه برداری خود را به دیگر زمینه های محدود داشته باشد . نویسنده همچنین درباره اهمیت مدل سازی داده های مناسب بحث می کند . او پیشنهاد می کند که مدل داده ها باید بر اساس دامنه کسب و کار و نه بر روی دامنه نرم افزار باشد . مدل داده ها باید نهادهای واقعی و روابط موجود در حوزه کسب و کار را نشان دهد . در نهایت ، خوهیم دید که این نرم افزار باید برای تسهیل تست طراحی شود . تست برای اطمینان از اینکه نرم افزار مطابق با الزامات دامنه کسب و کار است ضروری است. درواقع نکته مورد توجه ما اهمیت نگه داشتن نرم افزار ، جدا از دامنه کسب و کار وکسب اطمینان از این است که نرم افزار مطابق با الزامات دامنه کسب و کار است . زمینه های پراکنده ، مدل سازی داده های مناسب و قابلیت آزمایش ، همه ملاحظات مهم در هنگام طراحی نرم افزار است که نیازهای دامنه کسب و کار را برآورده می کند.در ادامه در مورد اهمیت معماری تمیز در توسعه نرم افزار بحث میشود . کتاب استدلال می کند که معماری تمیز در ایجاد سیستم های نرم افزاری قابل نگهداری ، مقیاس پذیر و غیر قابل بازیافت ضروری است . این فصل با معرفی مختصر به معماری نرم افزار آغاز می شود و آن را به عنوان فرایند طراحی یک سیستم نرم افزار برای پاسخگویی به الزامات کاربر تعریف می کند . کتاب بر اهمیت معماری خوب در توسعه نرم افزار تاکید می کند و بیان می کند که برای موفقیت هر پروژه نرم افزاری مهم است . نویسنده سپس مفهوم فرسایش ساختاری را معرفی می کند که زمانی اتفاق می افتد که یک سیستم بیش از حد پیچیده و دشوار شود . این می تواند منجر به کاهش بهره وری و افزایش در مقدار زمان و منابع مورد نیاز برای رفع اشکالات و پیاده سازی ویژگی های جدید شود . برای جلوگیری از فرسایش معماری ، کتاب اصول معماری تمیز را ارائه می دهد . این اصول شامل جدا کردن سیستم به لایه های متمایز، استفاده از رابط ها برای تعریف روابط بین لایه ها و اجرای اصل عدم وابستگی برای ترویج اتصال شل بین اجزا است . این فصل همچنین در مورد اهمیت تست و کیفیت کد در حفظ یک معماری تمیز بحث می کند . نویسنده استدلال می کند که تست باید بخشی جدایی ناپذیر از فرآیند توسعه باشد و باید هر دو به صورت دستی و از طریق ابزارهای خودکار انجام شود. به طور کلی، این فصل بر اهمیت معماری تمیز در توسعه نرم افزار تأکید می کند و مشاوره عملی در مورد چگونگی دستیابی به آن را فراهم می کند. با پیروی از اصول ذکر شده در فصل، توسعه دهندگان می توانند سیستم های نرم افزاری قابل نگهداری، مقیاس پذیر و غیر قابل پیش بینی را ایجاد کنند که نیازهای کاربران خود را برآورده می کنند.در ادامه بحث در مورد اهمیت ارائه و فروتنی در توسعه نرم افزار را داریم . رابرت مارتین بر نیاز توسعه دهندگان برای برقراری ارتباط موثر ایده های خود و انجام این کار با تواضع تاکید می کند . پس از بحث در مورد اهمیت ارتباطات و فروتنی، کتاب در مورد چگونگی استفاده از این ویژگی ها در توسعه نرم افزار صحبت می کند . بیان میشود که توسعه دهندگان باید تلاش کنند تا نرم افزاری ایجاد کنند که درک و نگهداری آن آسان است و این نیاز به تمرکز بر معماری تمیز دارد . کتاب در مورد چند اصل کلیدی معماری تمیز، از جمله جدایی از نگرانی ها ، لایه برداری و انتزاع بحث می کند . توضیح این است که این اصول می تواند به ایجاد نرم افزاری که ماژولارتر، قابلیت آزمایش آسانتر و کمتر مستعد خطا است کمک کند . سپس به بحث در مورد نقش ارائه دهنده در توسعه نرم افزار را داریم . کتاب توضیح می دهد که ارائه دهنده مسئول گرفتن داده های پیچیده و ارائه آن به روشی است که برای کاربران آسان است و بر اهمیت موجود بودن مستقل از منبع داده تاکید می کند . به طوری که می تواند به راحتی جایگزین یا اصلاح شود بدون اینکه بر سایر بخش های سیستم تأثیر بگذارد . به طور کلی، اهمیت ارتباطات ، تواضع و معماری تمیز در توسعه نرم افزار مورد تأکید است . این یک چارچوب برای توسعه دهندگان فراهم می کند تا نرم افزار را ایجاد کنند که به این شکل درک، حفظ و آزمایش آن آسان تر است، در حالی که همچنین بر اهمیت ارتباطات موثر و همکاری تاکید می کند.یک مرز خطی است که دو چیز را جدا می کند و در معماری نرم افزار به مرز بین اجزا اشاره می کند. ایده این است که هر جزء باید یک مرز به خوبی تعریف شده داشته باشد ، اما آنچه که یک مرز را تشکیل می دهد می تواند سخت تر باشد . در چارچوب مرزهای جزئی، مارتین استدلال می کند که گاهی اوقات مفید است که یک جزء با یک مرز جزئی داشته باشیم. این بدان معنی است که برخی از تعاملات با جزء خارج از مرز آن هستند، در حالی که دیگر بخش ها در داخل هستند . یکی از مزایای مرزهای جزئی این است که می تواند معماری را انعطاف پذیرتر کند . با داشتن اجزای دارای مرزهای جزئی، می توانیم بدون نیاز به تغییر کل معماری ، تغییراتی در سیستم ایجاد کنیم . یکی دیگر از مزایای آن این است که می تواند طراحی را مدولار تر کند ، که می تواند درک و نگهداری آن را آسان تر کند. با این حال، مشکلات بالقوه ای برای استفاده از مرزهای جزئی وجود دارد. یکی این است که می تواند طراحی را پیچیده تر کند ، زیرا نیاز به تفکر بیشتر برای تعیین اینکه مرزها باید کجا باشند دارد. یکی دیگر این است که می تواند دلیل آن را در مورد سیستم سخت تر کند، زیرا تعیین دقیق اینکه کدام تعاملات در داخل یا خارج از مرز قرار دارند ، دشوار است . به طور خلاصه، مفهوم مرزهای جزئی یک ابزار مفید در معماری نرم افزار است، اما باید به دقت و با فکر مورد استفاده قرار گیرد . با توجه به مزایای و معایب ، ما می توانیم یک معماری انعطاف پذیر تر و مدولار تر ایجاد کنیم که درک و نگهداری آن آسان تر است. هدف ما پی بردن به اهمیت معماری تمیز در جلوگیری از پیچیدگی غیر ضروری و کاهش خطر بدهی است . همچنین بر نیاز به مرزهای روشن بین اجزا و لایه ها در یک برنامه برای ترویج مدولار بودن و انعطاف پذیری تأکید می کنیم . کتاباهمیت توجه به تاثیر تغییرات در سیستم و تصمیم گیری آگاهانه در مورد جایی که خطوط بین اجزای مختلف را ترسیم می کند را برجسته می کند . به طور کلی، در اینجا بر اهمیت طراحی یک سیستم تاکید میشود که حفظ و مقیاس پذیری آن ،آسان است در حالی که به حداقل رساندن خطر بدهی و کاهش احتمال بروز مشکلات غیرمنتظره در آینده است. ما در ادامه مباحث با مفهوم The Main Speed مواجه خواهیم بود که به این ایده اشاره می کند که سرعت اصلی یک سیستم باید با آهسته ترین جزء در سیستم مشخص شود. به عبارت دیگر، عملکرد کلی سیستم نباید توسط سریع ترین جزء تعیین شود ، بلکه با کندترین بخش مشخص می شود. این یک مفهوم مهم برای نگه داشتن در هنگام طراحی و پیاده سازی سیستم ها است، زیرا می تواند اطمینان حاصل کند که سیستم کارآمد و پاسخگو است حتی زمانی که با اجزای آهسته تر سروکار دارد. در بحث سرویس ها توضیحات کتاب حول مفهوم خدمات بالا و کوچک می چرخد . نویسنده بر اهمیت جدا کردن نگرانی های یک برنامه به اجزای کوچکتر و قابل کنترل تر تأکید می کند . در این موضوعات با بحث در مورد مزایای استفاده از خدمات کوچک مانند تست آسان تر، تعمیر و نگهداری و مقیاس پذیری آغاز می شود . توضیح داده میشود که خدمات کوچک آسان تر برای درک و اصلاح هستند و می توانند به طور مستقل و بدون تاثیر بر بقیه سیستم، مقیاس یابند. نویسنده همچنین اهمیت استفاده از خدمات سطح بالا را برجسته می کند که یک انتزاع سطح بالایی از عملکرد سیستم را ارائه می دهد . این خدمات باید به لایه هایی که جدایی روشنی از نگرانی ها و مسئولیت ها را فراهم می کنند ، سازماندهی شود . سپس در مورد معاملات بین اتصال شل و اتصال سخت و چگونگی دستیابی به هر دو در یک سیستم واحد بحث می کند . نویسنده نشان می دهد که اتصال شل را می توان از طریق استفاده از رابط ها و انتزاع ها به دست آورد، در حالی که اتصال محکم را می توان از طریق حالت مشترک و انتقال پیام به دست آورد . این موضوعات با تاکید بر اهمیت استفاده از ابزار مناسب برای کار و اجتناب از پیچیدگی غیر ضروری به پایان می رسند. به طور خلاصه، این مبحث بر اهمیت استفاده از خدمات کوچک و خدمات سطح بالا سازماندهی شده به لایه ها برای دستیابی به اتصال شل و اتصال محکم تاکید می کند و سادگی و وضوح برای ایجاد سیستم های قابل نگهداری و مقیاس پذیر ضروری است.در پایان رابرت سی مارتین در مورد مفهوم مرزهای آزمون و چگونگی استفاده از آنها برای بهبود کیفیت سیستم های نرم افزار بحث می کند . مرزهای تست به مرزها یا رابط بین اجزای یک سیستم نرم افزاری که برای تست استفاده می شود اشاره می کنند . یک جزء با مرزهای آزمون روشن ، آسان تر برای تست و نگهداری خواهد بود . زیرا جداسازی و دستکاری اجزای فردی برای اهداف تست آسان تر خواهد بود . کتاب استدلال می کند که مرزهای آزمون برای دستیابی به سطح بالایی از کیفیت کد و قابلیت نگهداری ضروری است و نشان می دهد که توسعه دهندگان همیشه باید تلاش کنند تا اجزایی را با مرزهای تست تعریف شده ایجاد کنند و باید سیستم های خود را با چشم به سمت انجام تست به عنوان کارآمد طراحی کنند . نویسنده همچنین در مورد اهمیت ایجاد سلسله مراتبی از مرزهای آزمون، با اجزای کوچکتر و متمرکز تر با محدودیت های تست کمتر و اجزای بزرگتر و پیچیده تر که دارای مرزهای آزمایش بیشتری هستند، بحث می کند . با ایجاد سلسله مراتبی از مرزهای آزمون، توسعه دهندگان می توانند سیستم هایی ایجاد کنند که هم قابل آزمایش و هم مقیاس پذیر هستند. به طور کلی، اهمیت مرزهای آزمون در طراحی سیستم نرم افزار و چگونگی استفاده از آنها برای بهبود کیفیت کلی و حفظ سیستم های نرم افزار مورد تاکید است .در فصل 30 ام این کتاب به بررسی اهمیت و نحوه یکپارچه‌سازی بانک اطلاعاتی در یک سیستم نرم‌افزاری پرداخته شده است. در این فصل، نویسنده به اهمیت طراحی دقیق بانک اطلاعاتی و اینکه چگونه باید آن را به عنوان یک جزء از ساختار کل سیستم معرفی کنیم، پرداخته و بر اهمیت طراحی درست و بهینه بانک اطلاعاتی به منظور اجتناب از اشکالات و ارتقاء کارایی سیستم اشاره شده است. رابرت سی مارتین در این فصل به مباحثی همچون نحوه افزایش یکپارچگی بین بانک اطلاعاتی و لایه‌های دیگر سیستم، استفاده از الگوهای طراحی مناسب برای بانک اطلاعاتی، و نکاتی که باید در طراحی این قسمت از سیستم مدنظر قرار گیرد، می‌پردازد. همچنین اهمیت انطباق بانک اطلاعاتی با نیازهای کسب و کار و استفاده از استانداردهای مناسب نیز تاکید شده است.علاوه بر این، به انتخاب مناسب نوع دیتابیس، افزایش قابلیت اطمینان (reliability) و مقیاس‌پذیری (scalability) بانک اطلاعاتی، استفاده از الگوهای طراحی شیء ، رابطه (Object-Relational Design Patterns)، و نحوه یکپارچه‌سازی بانک اطلاعاتی با لایه‌های دیگر سیستم اشاره شده است . به طور کلی، در این فصل مؤلف به خواننده نشان می‌دهد که چگونه معماری تمیز در طراحی بانک اطلاعاتی می‌تواند به بهبود اداء و گسترش پروژه‌های نرم‌افزاری کمک کند.در ادامه رابرت سی مارتین به مفهوم و اهمیت معماری سیستم‌ها و تأثیر آن بر توسعه و نگهداری نرم‌افزارها پرداخته و بیان میشود که وب به عنوان یک جزء از کل سیستم، نقش بسیار حیاتی دارد و باید به عنوان یک رکن مهم در معماری نرم‌افزار در نظر گرفته شود.مارتین تأکید دارد که معماری تمیز به معنای جداکردن مسائل و بخش‌های مختلف سیستم باعث ایجاد انعطاف‌پذیری، قابلیت تغییر و نگهداری ساده‌تر می‌شود. او بر اهمیت اصول SOLID و تکنیک‌های معماری سطح بالا برای ایجاد ساختارهای کدی قابل فهم و توسعه‌پذیر تأکید می‌کند.همچنین، مارتین به اهمیت مستندسازی صحیح معماری و استفاده از الگوهای معماری معروف مانند MVC (مدل-ویو-کنترلر) و Dependency Injection (تزریق وابستگی) می‌پردازد. او توصیه می‌کند که توسعه‌دهندگان به توازن بین انعطاف‌پذیری و پایداری در معماری توجه داشته باشند و از اصول Clean Code (کد تمیز) در تمام لایه‌های سیستم استفاده کنند . این بخش به خوانندگان کمک می‌کند تا درک عمیق‌تری از اهمیت معماری تمیز در توسعه نرم‌افزارها، به ویژه در فضای وب، پیدا کنند و اصول مهمی را برای ایجاد سیستم‌های با کیفیت و سازگار با تغییرات معرفی می‌کند. در ادامه به اهمیت فریم ورک ها در معماری مدرن پرداخته میشود. و توضیح داده میشود که فریم ورک ها اجزای اصلی معماری هستند که به طور گسترده در ساخت و توسعه نرم افزارها استفاده می‌شوند. نویسنده به بررسی نحوه استفاده از فریم ورک ها در طراحی ساختارهای پایدار و قابل توسعه معماری مدرن پرداخته و روش‌های بهینه سازی استفاده از آن‌ها را شرح می‌دهد. این فصل به خواننده کمک می‌کند تا با دقت بیشتر به طراحی و پیاده سازی فرآیندهای معمارانه در پروژه‌های خود بپردازد. در این فصل، نویسنده به توضیح دقیق و جامع در مورد نقش و اهمیت فریم ورک ها در طراحی و توسعه سیستم‌های نرم‌افزاری می‌پردازد. فریم ورک ها به عنوان چارچوب‌های کلی برای ساختاردهی و توسعه سامانه‌های نرم‌افزاری استفاده می‌شوند. آن‌ها شامل قطعات کد، الگوهای طراحی، استانداردها و قوانین استفاده شده در چیدمان و اجزاء سامانه هستند. فرآیندهای تکنولوژيكي كه بيشتر اين روزها با استفاده از فضای ديجيتال صورت می گيرد، باعث شده است كه نقش فرآیندهایی نظير Project Management ، كنترل كيفي (Quality Control)، طبقات (Layers)، الگو ها (Patterns)، چارچوب ها (Frameworks) و ... حائز اهمیت شود. بخش‌های مختلف فصل 32 به بحث در مورد اجزاء مختلف فریم ورک ها پرداخته شده است. این بخش‌ها شامل تعاریف دقیق و جامع در مورد قطعات کد، الگوهای طراحی، استانداردها و قوانین استفاده شده در فرآیندهای تکنولوژيكي هستند.در ادامه فصل بعدی مجموعه این قوانین و افکار در مورد معماری را در یک مطالعه موردی کوتاه و ساده کنار هم و مورد مطالعه قرار میدهیم که هم فرآیندی را که یک معمار خوب استفاده می کند و هم تصمیماتی را که چنین معمار می گیرد، به تصویر می کشد.مطالعه موردی ما ،نرم‌افزاری برای وب‌سایتی است که فیلم می‌فروشد. ما یک سری ویدیو داریم که می خواهیم بفروشیم. ما آنها را در وب به افراد و مشاغل می فروشیم. افراد می‌توانند یک قیمت برای مشاهده ویدیوها بپردازند و قیمت دیگری برای دانلود آن ویدیوها و مالکیت دائمی آنها. افراد معمولاً هم به عنوان بیننده و هم به عنوان خریدار عمل می کنند. در مقابل، کسب‌وکارها اغلب افرادی دارند که ویدیوهایی را می‌خرند که دیگران تماشا خواهند کرد.تولیدکنندگان ویدئو باید فایل‌های ویدئویی، توضیحات نوشته شده و فایل‌های جانبی خود را با آزمون‌ها، مشکلات، راه‌حل‌ها، کد منبع و سایر مطالب ارائه کنند.مدیران باید توانایی این را داشته باشند که ویدیوها را به مجموعه اضافه و حذف کنند، و قیمت محصولات ویدیویی مختلف را تعیین کنند.اولین قدم ما در تعیین معماری اولیه سیستم، شناسایی بازیگران و مواردکاربری است.مطابق شکل زیر :شکل 1چهار بازیگر اصلی مشخص هستند. بر اساس اصل مسئولیت واحد، این چهار بازیگر، چهار منبع اصلی تغییر برای سیستم خواهند بود. هر بار که برخی از ویژگی های جدید اضافه می شود، یا برخی از ویژگی های موجود تغییر می کنند، این مرحله برای خدمت به یکی از این بازیگران به اجرا گذاشته می شود. بنابراین ما می خواهیم سیستم را به گونه ای تقسیم بندی کنیم که تغییر در یک بازیگر بر هیچ یک از بازیگران دیگر تأثیری نگذارد.یوزکیس های نشان داده شده در شکل 1 ، یک لیست کامل نیستند.که برای خلاصه سازی این کار انجام شده است . به عنوان مثال، ورودی و خروجی USE CASE ها را نمیتوانیم ببینیم . اکنون که ما ACTOR ها و USE CASE را میشناسیم ، میتوانیم یک معماری بر اساس کامپوننت های اولیه ایجاد کنیم . مطابق شکل 2 خطوط دوتایی در نقشه، مرزهای معماری را نشان می دهد. می توانیم پارتیشن بندی معمولی نماها، ارائه دهندگان، تعامل کنندگان و کنترلرها را مشاهده کنیم. هر کامپوننت در شکل 2 یک فایل jar. یا فایل dll . بالقوه را نشان می دهد. هر یک از این مؤلفه‌ها شامل نماها، ارائه‌کنندگان، تعامل‌کنندگان و کنترل‌کننده‌هایی است که به آن اختصاص داده شده‌اند.حال به کامپوننت های خاص برای نمایش کاتالوگ و ارائه کننده کاتالوگ توجه کنید. این روش نحوه برخورد با USECASE انتراعی VIEW CATALOG است .شکل 2در نتیجه نمودار معماری در شکل 2 ، شامل دو بعد جداسازی است. اولی جدایی بازیگران بر اساس اصل مسئولیت واحد است. و دومین بعد ، قانون وابستگی است. هدف هر دو جداسازی کامپوننت هایی است که به دلایل مختلف و با نسبت های متفاوت تغییر می کنند. دلایل مختلف به بازیگران مربوط است و نسبت های مختلف به سطوح مختلف خط مشی مربوط است . پس از ساختن کد به این روش میتوانیم نحوه توسعه سیستم را با یکدیگر هماهنگ و مطابقت دهیم و در هنگام تغییر شرایط ، گروه را به راحتی تغییر دهیم . ما میتوانیم کامپوننت ها را به هر روشی که معقول باشد ، در فایل های قابل تحویل و توسعه قرار دهیم و در هنگام تغییر شرایط ، گروه را به راحتی تغییر دهیم .محمد گنجیمحمد گنجیTue, 17 Oct 2023 00:51:37 +0330