هنگامی که افراد در صنعت نرم افزار در مورد “معماری” صحبت می کنند ، آنها به مفهوم تعریف شده خطرناکی از مهمترین جنبه های طراحی داخلی یک سیستم نرم افزاری اشاره می کنند. یک معماری خوب مهم است ، در غیر این صورت افزودن قابلیت های جدید در آینده کندتر و گرانتر می شود
تولید نرم افزار ها
تصمیمات مهم در زمینه تولید نرم افزار بسته به مقیاسی که در مورد آن فکر می کنیم متفاوت است. مقیاس رایج مقیاس یک برنامه است ، از این رو “معماری برنامه”. اولین مشکل در تعریف معماری برنامه این است که تعریف روشنی از اینکه یک برنامه چیست وجود ندارد. دیدگاه من این است که برنامه ها ساختاری اجتماعی هستند: مجموعه ای از کدها که توسط توسعه دهندگان به عنوان یک واحد واحد مشاهده می شود گروهی از عملکردها که مشتریان تجاری به عنوان یک واحد واحد مشاهده می کنند ابتکاری که صاحبان پول آن را یک بودجه واحد می دانند چنین تعریف شل شده منجر به بسیاری از اندازه های بالقوه یک برنامه می شود ، از چند تا چند صد نفر در تیم توسعه متفاوت است. (متوجه خواهید شد که من اندازه افراد را درگیر می کنم ، که به نظر من مفیدترین روش برای اندازه گیری چنین مواردی است.)
تفاوت کلیدی بین این و معماری سازمانی این است که درجه قابل توجهی از هدف واحد پیرامون ساخت اجتماعی وجود دارد.
مقایسه بین طراحی نرم افزار و معماری اولین بار در اواخر دهه 1960 انجام شد ، اما اصطلاح “معماری نرم افزار” تا دهه 1990 کاربرد گسترده ای نداشت. رشته علوم کامپیوتر از زمان شکل گیری با مشکلات مرتبط با پیچیدگی روبرو شده است. مشکلات اولیه پیچیدگی توسط توسعه دهندگان با انتخاب ساختارهای داده مناسب ، توسعه الگوریتم ها و با استفاده از مفهوم تفکیک نگرانی ها حل شد. اگرچه اصطلاح “معماری نرم افزار” در صنعت نسبتاً جدید است ، اما از اواسط دهه 1980 اصول اولیه این رشته به طور پراکنده توسط پیشگامان مهندسی نرم افزار اعمال می شود. تلاش های اولیه برای گرفتن و توضیح معماری نرم افزار یک سیستم نادرست و نامنظم بود ، که اغلب توسط مجموعه ای از نمودارهای جعبه و خط مشخص می شوند. در طول دهه 1990 تلاش مشترکی برای تعریف و کدگذاری جنبه های اساسی این رشته وجود داشت که تا امروز باعث پیشرفت بسیاربالای این رشته بوده است ..