کتاب Mastering Software Architecture

کتاب Mastering Software Architecture: A Comprehensive New Model and Approach (تسلط بر معماری نرم‌افزار: یک مدل و رویکرد جامع جدید) به بررسی و تحلیل عمیق اصول و شیوه‌های معماری نرم‌افزار می‌پردازد و هدف آن ارائه یک دیدگاه کل‌نگرانه و یکپارچه به این حوزه است.

نویسندگان با تاکید بر پیچیدگی‌های مربوط به طراحی سیستم‌های پیچیده، سعی در شناسایی الزامات بسترهای مختلف و نیازهای کسب و کار دارند و نشان می‌دهند که چگونه می‌توان با یکپارچگی جنبه‌های فنی، انسانی، و سازمانی، معماری‌های مؤثر و کارآمدی ایجاد کرد.

کتاب Mastering Software Architecture همچنین بر اهمیت ارتباطات مؤثر بین اعضای تیم، مدیریت تعادل‌های مختلف و انطباق با ساختارهای موجود در سازمان‌ها تأکید دارد و به معماران نرم‌افزار کمک می‌کند تا هم‌زمان با تغییرات مداوم فناوری و نیازهای بازار، به طراحی راه‌حل‌های پایدار و قابل توسعه بپردازند.

در ادامه مقدمه‌ای از کتاب Mastering Software Architecture را از زبان نویسنده شرح خواهیم داد.

مقدمه‌ای بر کتاب Mastering Software Architecture:

مقدمه: کل‌نگری در معماری نرم‌افزار

شما نمی‌توانید چیزها را با مبارزه با واقعیت‌های موجود تغییر دهید. برای تغییر چیزی، مدلی جدید بسازید که مدل موجود را قدیمی کند.

—R. Buckminster Fuller

یک دوره کارشناسی در ریاضیات کاربردی بر اصول و مفاهیم کلی تمرکز خواهد کرد و پیچیدگی‌ها را با کاهش ابعاد فضای مشکل ساده می‌کند. ما برای نظریه ساده‌سازی می‌کنیم و پیچیدگی واقعی واقعیت را نادیده می‌گیریم. یک جرم ممکن است به یک “رشته‌ی سبک و گلوله‌ناپذیر” متصل باشد. تنها پولی‌های کامل، سطوح بدون اصطکاک و سیستم‌هایی وجود دارند که همیشه در خلا کار می‌کنند.

بسیار گفته شده است که “معماری نرم‌افزار نمی‌تواند در خلا وجود داشته باشد”، با این حال، این خلا به ویژه فرار از آن بسیار دشوار است. این واقعیت با رویکردهای رایج بسیاری از آثار در این حوزه که تنها بر روی یک یا چند جنبه از آن در سطح انتزاعی تمرکز می‌کنند، پیچیده‌تر می‌شود.

در واقع، معماری جزء یک اکوسیستم زنده و پویا از انسان‌ها، تکنولوژی‌ها، شبکه‌ها، ماشین‌ها، مشتریان، رویاها و آرزوهاست. کاربرد معماری نیازمند آن است که انتزاع را به عینیت تبدیل کنیم و مدل‌هایی طراحی کنیم که تمام تکه‌های نظریه معماری را به همراه آشفتگی‌های واقعیتی که معماری باید در آن وجود داشته باشد، یکپارچه کند.

به‌طور تاریخی، تنها در طول یک دوره طولانی از یک حرفه با سابقه‌ای پرنوسان از موفقیت‌ها و شکست‌ها امکان اتصال این قطعات مجزا به یک درک بسیار بزرگتر وجود داشته است. یک نگاه جامع‌تر و کل‌نگر به این حوزه مدت‌هاست که لازم است و این دیدگاه یکپارچه، هدف بلندپروازانه‌ی «استاد شدن در معماری نرم‌افزار» است.

از میان تمام رشته‌های مهندسی که در طول تاریخ بشر پدید آمده‌اند، نرم‌افزار به‌طور قابل توجهی جوان‌ترین است. مهندسی عمران، مکانیک و نظامی طی هزاره‌ها تکامل یافته‌اند. مهندسی شیمی و برق چندین قرن به طول انجامیده است. در مقابل، مهندسی نرم‌افزار تنها از چند دهه پیش ظهور کرده است. ما هنوز بسیاری از چیزها را باید یاد بگیریم و کشف کنیم.

تنها در سال 1975 بود که اولین مفاهیم نرم‌افزار ساختاری شروع به ورود به واژگان صنعت کردند. در آن زمان، معماری مقدماتی به عنوان یک وحدت بین مهندسی نرم‌افزار و مهندسی سیستم‌ها شروع به ظهور کرد. در سال 1976، تعدادی از افراد آینده‌نگر آینده‌ای را دیدند که با سیستم‌های نرم‌افزاری به طور فزاینده‌ای پیچیده متشکل از اجزای متعدد که توسط تیم‌های مختلف ساخته و نگهداری می‌شوند، مشخص می‌شد.

این پیشگامان در فضای توسعه نرم‌افزار شروع به کشف ایده‌هایی در مورد اجزای سیستم، مدولاریتی و توصیف‌های مفهومی سطح بالاتر از سیستم‌های نرم‌افزاری کردند. دنیای در حال تغییر همچنین نیاز به تغییر نرم‌افزار داشت، بنابراین تلاش بیشتری برای رویکردهای نوآورانه جهت ساختاردهی بهینه کد برای قابل‌فهمی، نگهداری و گسترش صورت گرفت. تا سال 1990، اولین کتاب‌ها با تمرکز صریح بر آنچه ما حالا به آن معماری نرم‌افزار می‌گوییم منتشر شدند و صنعت به زودی باور کرد که اکسیری جادویی پیدا کرده است.

با این حال، به نظر می‌رسد محکوم شده‌ایم که بارها و بارها درک کنیم که، همانطور که فرد بروکس در سال 1986 و روی فیلدینگ در سال 2000 تأکید کردند، هیچ معجون جادویی وجود ندارد. متأسفانه، تفکر معجون جادویی هنوز در صنعت ما ریشه دارد.

در معماری نرم‌افزار، بهترین شیوه‌ها وجود ندارد؛ پاسخ‌های “صحیح” و جهانی و عینی وجود ندارد. تنها تعادل‌هایی وجود دارد. وزن این واقعیت به قدری قابل توجه است که نیل فورد و مارک ریچاردز این را به عنوان اولین قانون معماری نرم‌افزار به ثبت رسانده‌اند.

طراحی سیستم‌ها امروزه نیازمند ارزیابی بسیاری از تصمیمات، وزن‌گذاری بر تعادل‌های بسیاری و رسیدن به یک طراحی بهینه محلی برای یک پروژه، سیستم، زیرسیستم یا مؤلفه خاص نسبت به زمان تصمیم‌گیری است (هرچند که نیازهای سیستم در آینده تغییر خواهد کرد).

تصمیمات و تعادل‌ها در ابعاد بسیاری متنوع هستند، از فناوری تا انسانی و از محیطی تا سازمانی. برای اینکه حوزه معماری نرم‌افزار به تکامل خود ادامه دهد، مدل‌های جدیدی باید به کار گرفته شوند که چشم‌اندازی کل‌نگرتر اتخاذ کنند. الگوهای فردی، فناوری‌ها، شیوه‌ها و ابزارها ارزشی دارند و همچنان ضروری هستند، اما نشان داده‌اند که به تنهایی برای مؤثر کردن یک معمار کافی نیستند.

به چالش‌های معماری امروز توجه کنید. از زمانیکه برد کخ ابتدا پیشنهاد کرد که شاید “معجون جادویی” وجود داشته باشد، ما آموخته‌ایم که مسیرهای متعددی برای طراحی سیستم قابل دسترس است و هر مسیر نتایج متفاوتی به همراه دارد. نتیجه‌ای که برای یک پروژه بهترین است، برای پروژه‌ای دیگر بهینه نخواهد بود. سیستم‌های مختلف به مجموعه‌های متفاوتی از ویژگی‌های معمارتی و قابلیت‌های ذاتی سیستم نیاز دارند.

این قابلیت‌ها باید از الزامات و نیازهای کسب و کار به وجود آیند، که هرگز به زبان و اصطلاحات خاص حوزه معمار یا برنامه‌نویس منتقل نمی‌شوند. علاوه بر این، زمانی که این قابلیت‌ها بیان نمی‌شوند، باید استنباط گردند. اگر در این وظیفه بنیادی ناکام بمانیم، ناممکن است که به عنوان یک معمار مؤثر عمل کنیم.

حتی اگر یک معمار بتواند این الزامات معماری را به درستی استنباط کند، اگر کوزه‌ی مجازی معمار فقط شامل تعداد نسبتاً کمی از الگوها و پیاده‌سازی‌های بالقوه باشد و از مجموعه‌ای پیچیده‌تر و دقیق‌تر از ابزارها و مدل‌های ذهنی برای استخراج معماری‌ها بی‌بهره باشد، مؤثر بودن آن به شدت محدود خواهد شد.

با فرض اینکه معمار بتواند یک معماری هدف را به‌طور کامل طراحی کند، این نیز کافی نیست. دیدگاه و معماری او باید با دقت بالا منتقل شود، به‌طوری‌که تیم‌های اجرا قادر به درک و اجرای مؤثر آن باشند. اگر مهم‌ترین جزئیات طراحی در ترجمه گم شوند، حتی یک معماری بهینه برای یک سیستم نیز بی‌فایده خواهد شد.

اجرا کردن معماری درون یک سازمان چالش دیگری را ارائه می‌دهد. تقریباً هر تصمیمی که یک معمار می‌گیرد به چالش کشیده خواهد شد. بسیاری از افراد با دانش و تجربه مسئول اجرای هر پروژه‌ای هستند.

این افراد ممکن است نظرات متفاوتی در مورد چگونگی ساخت سیستم داشته باشند. معماری ممکن است با سوگیری‌های موجود در سازمان سازگار نباشد؛ با این حال، سیستم کلان باید منسجم باشد که نیازمند رعایت استانداردها و کنوانسیون‌های معماری است. برای اینکه مؤثر باشد، معمار نه تنها باید در هنر تحلیل نیازها و طراحی سیستم مهارت داشته باشد، بلکه باید یک ارتباط‌گر و عامل تغییر ماهر نیز باشد. اگر نتوانیم توافقی میان ذینفعان و تیم‌های پروژه ایجاد کنیم، بسیاری از کارهای طراحی بی‌فایده خواهد بود.

سرانجام، معمار باید از واقعیت‌های پیچیده آگاه باشد که در بحث‌های نظری معماری به راحتی نادیده گرفته می‌شوند، اما در عمل نرم‌افزار نمی‌توان نادیده گرفت. این‌ها عوامل خارجی مانند ماهیت، ساختار، و بلوغ سازمان؛ مهارت‌ها، بلوغ و شیوه‌های تیم‌ها و عواملی هستند که محیطی که پروژه در آن وجود دارد را تحت تأثیر قرار می‌دهند.

معماری دیگر به سادگی مجموعه‌ای از بهترین شیوه‌ها برای سازماندهی کدهای پیچیده یا ابزارهای مدل‌سازی برای توصیف یک سیستم در سطح بالا نیست. این تنها درباره الگوهای جدیدی که در بیست سال گذشته به وجود آمده‌اند نیست. جنبه‌های اساسی زیادی از معماری نرم‌افزار فراتر از “چه” و “چگونه” وجود دارد که نیاز به بررسی بیشتری دارد. به اختصار، برای اینکه حوزه ما به تکامل خود ادامه دهد، باید ایده کل‌نگری را در رویکرد خود به معماری پذیرا باشیم. کاری که در پی می‌آید یک تلاش بلندپروازانه برای انجام همین هدف است.

سرفصل‌های کتاب Mastering Software Architecture:

• Cover
• Front Matter
• Section 1. Foundations
  • 1. The Scope and Role of Architecture
  • 2. Breadth of Knowledge: The Architect’s Superpower
  • 3. Capabilities: The Language of the Architect
  • 4. Aligning on Vision and Architectural Requirements
  • 5. KPIs, Metrics, and Data-Driven Architecture Decisions
  • 6. Architectures Are Not “Chosen,” They Are Designed
  • 7. Architectural Constraints: Designing for Deterministic Capabilities
  • 8. Architectural Styles: The Tailor-Made Pattern Language
  • 9. Architectural X Factors: Environment, Organization, and Teams
  • 10. Abstract Styles: A New Look at Patterns
• Section 2. Patterns, Abstract Styles, and Architecture As a Continuum
  • 11. Architecture As a Multifaceted Continuum
  • 12. The Layered Monolith Abstract Style
  • 13. The Distributed N-Tier Architecture Abstract Style
  • 14. The Modular Monolith Abstract Style
  • 15. The Service-Based Abstract Style
  • 16. The Microservices Abstract Style
  • 17. Choreographed Event-Driven Abstract Style
  • 18. Orchestrated Event-Driven Abstract Style
  • 19. The Space-Based Abstract Style
  • 20. The Microkernel Abstract Style
  • 21. Summary of Constraints and Abstract Styles
• Section 3. Executing Architecture Effectively
  • 22. Deriving a Tailor-Made Architecture
  • 23. Paved Roads and Variances
  • 24. Documenting Architecture
  • 25. Architectural Enforcement and Governance
  • 26. The Art of Being an Architect
• Back Matter

جهت دانلود کتاب Mastering Software Architecture می‌توانید پس از پرداخت، دریافت کنید.