در توسعه نرم‌افزارهای موفق و انتخاب یک معماری مناسب برای آنها اهمیت قابلیت نگهداری و یا Maintainability بسیار بالا است. اصولی که در این درس فرا خواهید گرفت به شما کمک می کند تا بتوانید تصمیم های مناسبی در رابطه با معماری نرم‌افزار خود اتخاذ کنید که در نهایت وب اپلیکیشن نهایی تمیزتر و با قابلیت نگهداری بالاتری توسعه داده شود. به طور کلی تمامی این اصول ها سعی می‌کنند که به شما روش هایی را ارائه دهند که به اپلیکیشن خود را از کامپوننت ها و یا اجزای تشکیل دهنده مجزا ایجاد کنید. این اجزای تشکیل دهنده نباید tightly coupled باشند. به عبارت دیگر نباید بین این اجزای تشکیل دهنده در هم تنیدگی سخت وجود داشته باشد که با تغییر کردن یک قسمت به قسمت های دیگر نیز تحت الشعاع قرار بگیرند. در عوض این کامپوننت ها می بایست بتوانند با روش‌های مختلفی از قبیل Explicit Interface ها و یا messaging systems ها با یکدیگر در ارتباط بوده و با ارسال و دریافت کردن پیامهایی عملیات مورد نظر خود را انجام بدهند.
اولین اصل مهمی که می‌خواهیم در رابطه با آن صحبت کنیم اصل Separation of concerns یا تقسیم کردن حوزه های مختلف نرم افزار می باشد در همین ابتدای کار توصیه می‌کنیم که به جای ترجمه کردن این عبارت سعی کنید مفهوم آن را فرا گرفته و از خود این عبارت استفاده بفرمایید و اساس اصل Separation of concerns زمانی که یک نرم‌افزار توسعه داده می شود می بایست قسمت‌ها و حوزه‌ها و یا همان Concern های مختلف آن بر اساس عملکردی که دارند از یکدیگر تفکیک بگردند. برای مثال فرض کنید که یک وب اپلیکیشن وجود دارد که logic مورد نظر برای انتخاب کردن محصولات فروشگاه و سپس فرمت بندی کردن آنها در آن پیاده سازی شده است. در همین جمله می بینید که دو عملکرد متفاوت یعنی یکی انتخاب کردن عناصر برای نشان دادن به کاربر و دو فرمت بندی کردن آنها قرار گرفته است. رفتار مورد نظر برای انتخاب کردن این عناصر می‌بایست نسبت به رفتار مورد نظر برای فرمت بندی کردن آنها از یکدیگر تفکیک بگردند. به عبارت دیگر چون دو چون این دو مورد دو Concern و یا حوزه متفاوت به حساب می‌آیند نمی بایست که در درون هم پیاده‌سازی بگردند.
از نقطه نظر معماری، اپلیکیشن ها را می‌توان به صورت منطقی طوری ایجاد کرد که از این اصل با تفکیک کردن core business behavior ها از logic های مربوط به infrastructure و user interface بهره مند شود. ایده‌آل داستان این است که بین business rules و business logic در یک پروژه کاملاً مجزا قرار بگیرد و به هیچ پروژه دیگری درsolution وابستگی نداشته باشند. این موضوع کمک می‌کند که business model به سادگی تست پذیر شود و بدون tightly coupled بودن به implementation detail های سطح پایین بتواند تکامل پیدا کند. تمامی واژگانی که در این جملات خواندید همگی واژگان فنی هستند بنابراین از ترجمه کردن آن ها جلوگیری شده است. اصل Separation of concerns یک موضوع بسیار مهم و یک اصل اساسی در توسعه نرم‌افزارهای موفق به حساب می‌آیند. استفاده کردن از لایه ها در معماری های وب اپلیکیشن ها نیز روش معمولی برای به دست آوردن Separation of concerns می باشد.
منبع: وبسایت پرووید
