خلاصه‌ای از پنج ویدئو حوزه معماری نرم‌افزار

(این مطلب برای تمرین درس معماری نرم افزار مقطع کارشناسی ارشد - دکتر صادق علی اکبری تهیه شده.)

Democratising Software Architecture • Eoin Woods • GOTO 2023

در این ویدئو، اوون وودز، مهندس ارشد شرکت Indava، در مورد اهمیت معماری نرم افزار در عصر دیجیتال بحث می کند. او توضیح می دهد که پلتفرم ها به جای برنامه های کاربردی مستقل، رایج تر می شوند و نیاز به معماری نرم افزاری انعطاف پذیر و سازگار افزایش می یابد.

اوودز چالش های معماری نرم افزار در دنیای دیجیتال را برجسته می کند، از جمله:

• ناشناخته های بیشتر در مورد نیازهای تجاری
• نیاز به انتشار سریعتر و مکررتر
• وابستگی به خدمات ابری

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

اوودز پنج جنبه مهم کار معماری در دنیای پیوسته امروز را خلاصه می کند:

• ارائه رهبری فنی
• تمرکز بر ویژگی های کیفیت
• مدیریت بدهی فنی
• تصمیم گیری به عنوان مصنوعات درجه یک
• اجرای حلقه های بازخورد

او همچنین بر اهمیت مستندسازی حداقلی و قابل استفاده، مدیریت بدهی فنی و حلقه های بازخورد تأکید می کند.

در نهایت، اوودز تغییر از معماران به رهبران و مشاوران قابل اعتماد را برجسته می کند. او مطالعه بیشتر در مورد معماری پیوسته را تشویق می کند و هدف مشترک را برای مهم و مستمر کردن معماری در عصر دیجیتال بیان می کند.

در اینجا یک نسخه بازنویسی شده از متن است که سعی می کند روان تر و خواناتر باشد:

اهمیت معماری نرم افزار در عصر دیجیتال

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

معماری نرم افزار به تیم های توسعه کمک می کند تا سیستم هایی بسازند که ویژگی های کیفیت مورد نیاز کسب و کار را برآورده کند. این ویژگی ها می تواند شامل عملکرد، مقیاس پذیری، امنیت و قابلیت دسترسی باشد.

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

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

در اینجا پنج جنبه مهم کار معماری در دنیای پیوسته امروز آورده شده است:

• ارائه رهبری فنی: معماران باید رهبران فنی باشند که ذینفعان را در مورد نگرانی های فنی راهنمایی می کنند.
• تمرکز بر ویژگی های کیفیت: معماران باید بر ویژگی های کیفیت مورد نیاز کسب و کار تمرکز کنند.
• مدیریت بدهی فنی: معماران باید بدهی فنی را شناسایی و مدیریت کنند تا از ایجاد مشکلات در آینده جلوگیری کنند.
• تصمیم گیری به عنوان مصنوعات درجه یک: معماران باید تصمیمات معماری را به عنوان مصنوعات درجه یک ثبت و مستند کنند.
• اجرای حلقه های بازخورد: معماران باید حلقه های بازخورد را برای دریافت بازخورد از ذینفعان و بهبود کار خود اجرا کنند.

معماری پیوسته یک رویکرد انعطاف پذیر و سازگار است که می تواند به تیم های توسعه در ساخت سیستم های با کیفیت در عصر دیجیتال کمک کند.

https://www.youtube.com/watch?v=nchRmYvUf2Y

What Software Architecture Should Look Like • Dave Farley • GOTO 2022

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

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

وی به تعریف Grady Booch اشاره کرده که معماری را به عنوان تصمیمات مهم طراحی تعریف کرده و بر اهمیت این تصمیمات با هزینه تغییر تأکید دارد. هرچند فارلی با این تعریف موافق است، اما معتقد است که این تعریف به عنوان یک راهنمای عملی برای ساخت یک سیستم از ابتدا کافی نیست. به جای اینکه از یک رویکرد تکاملی به معماری تأکید کند، وی با تصحیح محدودیت‌های اعمال شده برای طراحی، به سمت سیستم میل می‌کند.

فارلی مفهوم "نقشه گردشگری" را به عنوان ابزاری برای هدایت تکامل سیستم معرفی می‌کند. این نقشه نشان دهنده درک مشترک توسعه‌دهندگان خبره است و به عنوان وسیله‌ای برای بحران در مورد ایده‌های طراحی و بررسی مفاهیم انتخاب‌های طراحی عمل می‌کند. او با تعریف Ralph Johnson از معماری به عنوان چیزهایی که توسعه‌دهندگان در ابتدای پروژه به درستی دست یافته‌اند موافق است، اما اذعان دارد که این درک احتمالاً در طول زمان تغییر خواهد کرد.

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

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

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

سخنران پیشنهاد می کند که مهم است که از جایی شروع کنید و یک طرح اولیه بر اساس درک مشکل و تجربه ایجاد کنید. این طرح اولیه باید به عنوان یک آزمایش تلقی شود و تمرکز باید بر روی کار تدریجی و تکراری باشد.

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

سخنران نمونه‌ای از معماری سیستم لایه‌ای را ارائه می‌دهد که توسط یک پایگاه داده رابطه‌ای پشتیبانی می‌شود. این معماری برای سیستم‌هایی با تعداد متوسط کاربر و ویژگی‌های ساده CRUD مناسب است. با این حال، مهم است که مقیاس پذیری را نیز در نظر بگیرید. پایگاه داده های رابطه ای ممکن است در زمینه های خاص مقیاس خوبی نداشته باشند.

سخنران اهمیت تفکر در مورد معماری یک سیستم را به جای تمرکز بر ابزارها برجسته می کند. آنها موردی را ذکر می کنند که در آن یک تیم بدون در نظر گرفتن فقدان حفاظت از تراکنش، از یک پایگاه داده NoSQL استفاده کرد. این منجر به ناهماهنگی و از دست دادن داده ها شد.

در اینجا خلاصه ای از نکات اصلی سخنران آورده شده است:

• طراحی بزرگ جلو می تواند غیر ضروری یا حتی مضر باشد.
• مهم است که از جایی شروع کنید و یک طرح اولیه ایجاد کنید.
• طرح اولیه باید به عنوان یک آزمایش تلقی شود و تمرکز باید بر روی کار تدریجی و تکراری باشد.
• هیچ معماری واحدی برای همه کاربردها مناسب نیست.
• مهم است که مقیاس پذیری را نیز در نظر بگیرید.
• تفکر در مورد معماری یک سیستم مهمتر از تمرکز بر ابزارها است.

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

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

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

در اینجا خلاصه ای از نکات اصلی سخنران آورده شده است:

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

https://www.youtube.com/watch?v=Eg_dapdKCHU

Devnexus 2022 - Keynote - Software Architecture by Example - Neal Ford

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

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

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

سخنران توضیح می دهد که این ویدئو بر جنبه طراحی سازه و معماری نرم افزار در شغل معمار نرم افزار تمرکز خواهد داشت. آنها اشاره می کنند که در این فرآیند دو فعالیت وجود دارد: تعیین ویژگی های معماری و انتخاب نقطه شروع برای سبک معماری. آنها از ترتیب ارائه شده در کتاب خود پیروی می کنند که با تعیین ویژگی های معماری شروع می شود.

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

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

سخنران سه بخش از تعریف خود را برای ویژگی های معماری معرفی می کند:

• توجه به طراحی غیر دامنه: ویژگی های معماری بر جنبه های فنی برنامه تأثیر می گذارند، اما الزامات مستقیماً توسط کاربران یا مشتریان بیان نمی شوند.
• تأثیر بر ساختار: ویژگی های معماری بر نحوه سازماندهی و اجرای سیستم تأثیر می گذارند.
• حیاتی یا مهم برای موفقیت برنامه: ویژگی های معماری برای موفقیت برنامه حیاتی یا مهم هستند.

آنها همچنین اصلاح کننده ویژگی های معماری آشکار در مقابل ضمنی را ذکر می کنند. مشخصه های صریح به صراحت مورد استفاده قرار می گیرند، در حالی که ویژگی های ضمنی بر تصمیم گیری ها تأثیر می گذارند حتی اگر به صراحت بیان نشده باشند.

به طور کلی، این ویدئو یک نمای کلی از دوره معماری نرم افزار ارائه می دهد و مفهوم ویژگی های معماری و اهمیت آنها را در فرآیند طراحی معرفی می کند.

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

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

سخنران مفهوم "کمترین بدترین طراحی" را معرفی می کند که به جای تلاش برای راه حل کامل، بر یافتن بهترین راه حل برای مجموعه معینی از الزامات و محدودیت ها تمرکز می کند. آنها توضیح می دهند که ویژگی های معماری اغلب هم افزایی هستند و می توانند بر یکدیگر تأثیر بگذارند، بنابراین یافتن تعادل مناسب مبادلات بسیار مهم است.

سپس به ویژگی های معماری عملیاتی، مانند عملکرد، مقیاس پذیری، کشش، قابلیت اطمینان و یکپارچگی داده ها می پردازند. این ویژگی ها به ویژه در معماری های مدرن مانند میکروسرویس ها مهم هستند، زیرا به همکاری بین عملیات، معماری و تیم های DevOps نیاز دارند.

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

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

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

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

سخنران توضیح می دهد که انتخاب یک سبک معماری باید بر اساس عوامل مختلفی مانند الزامات عملکردی، الزامات غیر عملکردی، محدودیت های فنی، و محیط اجرا انجام شود. آنها همچنین بر اهمیت مشارکت ذینفعان تجاری و فنی در فرآیند انتخاب سبک معماری تأکید می کنند.

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

سخنران فرآیند طراحی معماری منطقی را به چهار مرحله تقسیم می کند:

1. شناسایی اجزای اولیه: این مرحله شامل شناسایی اجزای بنیادی سیستم است که عملکردهای کلیدی آن را فراهم می کنند.
2. تخصیص الزامات به اجزا: این مرحله شامل تخصیص الزامات عملکردی و غیر عملکردی به اجزای شناسایی شده است.
3. تجزیه و تحلیل نقش ها و مسئولیت ها: این مرحله شامل شناسایی نقش های مختلف در سیستم و مسئولیت های آنها است.
4. تجزیه و تحلیل ویژگی های معماری: این مرحله شامل شناسایی ویژگی های معماری کلیدی سیستم، مانند مقیاس پذیری، قابلیت اطمینان، و امنیت است.

سخنران بر اهمیت طراحی تکراری در فرآیند طراحی معماری منطقی تأکید می کند. آنها توضیح می دهند که طراحی معماری منطقی یک فرآیند پویای است که باید در طول توسعه سیستم تنظیم شود.

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

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

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

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

سخنران به ابزاری به نام Excalidraw اشاره می کند که یک ابزار تخته سفید مشترک رایگان است که برای ایجاد نمونه های اولیه عالی است. آنها توضیح می دهند که ظاهر خشن و آنالوگ خطوط و فونت‌ها در Excalidraw کمک می‌کند تا نشان دهد که طراحی هنوز در مرحله تکراری است و به اتمام نزدیک نیست.

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

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

سخنران توضیح می دهد که این تحلیل نیاز به یک معماری توزیع شده را آشکار می کند. آنها توضیح می دهند که یک معماری توزیع شده سیستم را به اجزای مستقل تقسیم می کند که می توانند به صورت مستقل توسعه و مدیریت شوند. این امر امکان مقیاس پذیری و قابلیت اطمینان را بهبود می بخشد.

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

به طور کلی، سخنران بر اهمیت در نظر گرفتن ویژگی های معماری و انتخاب سبک معماری مناسب بر اساس نیازهای خاص پروژه تاکید می کند.

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

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

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

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

در اینجا برخی از تغییرات خاص که انجام دادم آورده شده است:

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

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

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

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

https://www.youtube.com/watch?v=KWKrSw_wI3s

Coevolution of Architecture & Code - Closing The Gap • Dave Thomas • YOW! 2022

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

سخنران همچنین در مورد شکاف مدل-کد صحبت می کند، که به این ایده اشاره دارد که کد تمایل به فرار از معماری دارد. آنها اشاره می کنند که کد اغلب از دیدگاه معماری اصلی جدا می شود و منجر به عدم همسویی بین این دو می شود. برای جلوگیری از این امر، سخنران بر اهمیت تکامل مشترک معماری و کد تأکید می کند.

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

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

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

در مجموع، سخنران بر نیاز به یک رویکرد تکاملی مشترک به معماری و کد، با آزمایش مداوم، معماری قابل مشاهده و تمرکز بر دانش دامنه تأکید می کند.

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

سخنران بر اهمیت آزمایش کافی هنگام ایجاد تغییرات در کد تأکید می کند. آنها استدلال می کنند که آزمایش به اطمینان از اینکه تغییرات باعث شکست کد نمی شوند کمک می کند. آنها همچنین بر اهمیت بهبود مستمر تأکید می کنند. این بدان معناست که کد باید به طور مداوم بهینه شود و با نیازهای کاربر سازگار شود.

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

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

برای پرداختن به این چالش ها، سخنران تمرین معماری پیوسته را پیشنهاد می کند. آنها بر لزوم مشاهده و به روز نگه داشتن معماری با استفاده از تکنیک هایی مانند نسخه سازی و مستندسازی تاکید می کنند. آنها همچنین بر اهمیت به اشتراک گذاری تصویر بزرگ معماری و مدیریت آن به گونه ای که گویی یک کد است، تأکید می کنند.

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

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

سخنران داستان سرایی را به عنوان راهی موثر برای انتقال اطلاعات معماری برجسته می کند. آنها استدلال می کنند که معماران یا مهندسان اصلی اغلب بهترین داستان نویسان هستند زیرا تجربه و دانش عمیقی از سیستم دارند.

سخنران سه تجربه شخصی را برای نشان دادن قدرت داستان سرایی در درک معماری به اشتراک می گذارد. در مثال اول، آنها در مورد یادگیری سیستم عامل Xerox Data Systems از طریق توضیح دقیق و از کار افتادن سیستم برای درک علت خرابی صحبت می کنند. در مثال دوم، آنها در مورد یک جلسه آموزشی در Nortel صحبت می کنند که در آن به استخدام های جدید در مورد پردازش تماس از طریق نمودارهای تعاملی و داستان سرایی آموزش داده شد. در مثال سوم، آنها در مورد شرکت خود صحبت می کنند، جایی که آنها یک مدل ساده از دیدگاه خود برای در دسترس قرار دادن Smalltalk بر روی پلتفرم های مختلف داشتند.

سخنران همچنین به مشارکت آنها در ساخت Eclipse و Java اشاره می کند، جایی که داستان سرایی نقش مهمی در ایجاد یک مدل ذهنی از معماری ایفا کرد. آنها اهمیت این داستان ها را در هدایت فرآیند توسعه و توانمندسازی تیم ها برای همکاری موثر با یکدیگر برجسته می کنند.

برای به تصویر کشیدن هر چه بیشتر معماری به شکل بتنی، گوینده چندین رویکرد را پیشنهاد می کند. اینها شامل گرفتن تعاریف API و نسخه سازی آنها، استفاده از زیرساخت به عنوان ابزار کد مانند Palumi یا CDK، استفاده از نمودارها به عنوان کد برای توصیف بصری سیستم، و استفاده از کدهای محدود شده با مدل یا مدل های UML خاص صنعت است. سخنران همچنین به روند رو به رشد ابزارهای کم‌کد اشاره می‌کند و پیش‌بینی می‌کند که آنها ممکن است شبیه برخی از مفاهیم مورد بحث در قسمت‌های قبلی ویدیو شوند.

در مجموع، سخنران بر اهمیت تسخیر و انتقال ماهیت معماری از طریق داستان گویی و ابزارها و تکنیک های مختلف تاکید می کند.

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

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

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

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

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

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

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

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

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

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

https://www.youtube.com/watch?v=slGZMTFPElo

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

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

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

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

سخنران پنج افسانه دیگر در مورد معماری نرم افزار را نیز مورد بررسی قرار می دهد. این افسانه ها عبارتند از:

• معماری نرم افزار فقط مربوط به کد است.
• معماری نرم افزار یک کار یکباره است.
• معماری نرم افزار فقط توسط معماران انجام می شود.
• معماری نرم افزار یک فعالیت فنی است.
• معماری نرم افزار یک فعالیت غیرقابل اندازه گیری است.

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

سخنران همچنین می گوید که معماری نرم افزار یک فرآیند پیوسته است که باید در طول عمر سیستم ادامه یابد. او می گوید که معماری نرم افزار باید به تغییرات نیازهای کاربر و فناوری پاسخ دهد.

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

در اینجا خلاصه ای از سخنرانی آورده شده است:

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

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

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

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

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

از نظر نمودار و ارائه طرح ها، سخنران این مفهوم را کهUML ضروری است به چالش می کشد. او تصدیق می کند که بسیاری از مردم UML را بسیار پیچیده یا قدیمی می دانند. در عوض، او استفاده از تخته وایت برد یا سایر ابزارهای بصری را برای ارتباط موثر طرح ها پیشنهاد می کند.

خلاصه ای از نکات کلیدی این قسمت از سخنرانی آورده شده است:

• طراحی و معماری پیشرو برای توسعه نرم افزار مهم است.
• تیم‌ها باید زمینه، دامنه و الزامات سیستم را در نظر بگیرند.
• رهبری فنی در معماری نرم افزار نقش مهمی ایفا می کند.
• یک رویکرد مشارکتی برای معماری نرم افزار مطلوب است.
• معماران باید کد تولید بنویسند.
• UML ضروری نیست.

چند نکته اضافی برای توسعه دهندگان نرم افزار آورده شده است:

• توسعه دهندگان باید درک اساسی از معماری نرم افزار داشته باشند.
• توسعه دهندگان باید درک کنند که معماری یک فرآیند مستمر است.
• توسعه دهندگان باید با معماران همکاری کنند تا یک معماری موثر ایجاد کنند.
• توسعه دهندگان باید از ابزارها و تکنیک های مناسب برای مستندسازی و ارتباط معماری استفاده کنند.

به طور کلی، سخنران بر ماهیت چند وجهی نقش معماری نرم افزار تأکید می کند، که هم به مهارت های فنی و هم به مهارت های نرم نیاز دارد. او معماران را تشویق می کند که به طور مداوم مهارت های خود را بیاموزند و توسعه دهند تا رهبران و همکاران موثری باشند.

اهمیت نمودارها در معماری نرم افزار می پردازد و مدل C4 را معرفی می کند. او توضیح می دهد که نمودارها مانند نقشه هایی هستند که به تیم ها اجازه می دهند به طور موثر ارتباط برقرار کنند و مکالمات متفاوتی با مخاطبان مختلف داشته باشند.

مدل C4 از نمودارهای سلسله مراتبی تشکیل شده است که سطوح مختلفی از جزئیات را در سیستم های نرم افزاری نشان می دهد. چهار نوع نمودار در مدل C4 وجود دارد:

• Context: این نمودار نمای کلی از سیستم را نشان می دهد و شامل اجزای اصلی آن و نحوه ارتباط آنها با یکدیگر است.
• Container: این نمودار اجزای اصلی سیستم را به گروه های منطقی تقسیم می کند.
• Component: این نمودار اجزای فردی سیستم را نشان می دهد.
• Code: این نمودار کد منبع سیستم را نشان می دهد.

مدل C4 مستقل از علامت گذاری است، به این معنی که تیم ها می توانند از نمادهای مختلفی مانند جعبه ها و خطوط، UML یا ArchiMate استفاده کنند.

سخنران همچنین به ابزاری به نام Structurizer DSL اشاره می کند که یک زبان مخصوص دامنه است که از مدل C4 پشتیبانی می کند و امکان ایجاد نمودارها را به صورت مختصر فراهم می کند. این ابزار همچنین از نمودارهای معماری ابری پشتیبانی می کند.

سخنران استفاده از نمودارها را به عنوان کد توصیه می کند که شامل ایجاد نمودارها با استفاده از قالب متنی یا کد زبان برنامه نویسی است. او ساختارساز DSL و رابط خط فرمان همراه آن را معرفی می کند که می تواند نمودارهای متعددی را در قالب های مختلف تولید کند.

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

سخنران در پایان از توسعه دهندگان می خواهد که به دقت در مورد تصمیمات خود فکر کنند و سرویس های میکرو را بدون برنامه ریزی و طراحی مناسب اتخاذ نکنند.

خلاصه ای از نکات کلیدی این قسمت از سخنرانی آورده شده است:

• نمودارها ابزارهای مهمی برای ارتباط و مستندسازی معماری نرم افزار هستند.
• مدل C4 یک چارچوب نموداری محبوب برای معماری نرم افزار است.
• نمودارها را می توان به عنوان کد ایجاد کرد که مزایای خاصی را ارائه می دهد.
• یک معماری خوب چابکی را امکان پذیر می کند.
• انتخاب یک معماری مناسب برای نیازهای خاص شما مهم است.
• سرویس های میکرو می توانند برای بهبود چابکی مفید باشند، اما باید به دقت برنامه ریزی و طراحی شوند.

چند نکته اضافی برای توسعه دهندگان نرم افزار:

• توسعه دهندگان باید درک اساسی از نمودارها و مدل C4 داشته باشند.
• توسعه دهندگان باید بتوانند از ابزارهای و تکنیک های مناسب برای ایجاد و استفاده از نمودارها استفاده کنند.
• توسعه دهندگان باید در هنگام انتخاب یک معماری برای نیازهای خاص خود دقت کنند.

https://www.youtube.com/watch?v=9Az0q2XHtH8