مرور ارائه انجام شده در کنفرانس اینجا قرار دارد را می‌خواهیم انجام دهیم.
سخنران، Stefan Tilkov، مفهوم معماری "به اندازه کافی خوب" را در زمینه توسعه نرم افزار مورد بحث قرار می‌دهد. او استدلال می‌کند که معماری یک راه حل یکسان نیست و بهترین معماری برای یک پروژه خاص به نیازها و محدودیت های خاص آن پروژه بستگی دارد. او همچنین تاکید می‌کند که معماری یک فرآیند مداوم است که باید با تغییر پروژه دائما در حال تغییر باشد و با رشد سازمان نیز همگام باشد.
همچنین سخنران تلاش می‌کند چندین مورد را با خطاهای احتمالی و راحل‌های خود بیان کند
توسعه پذیری غیر قابل توسعه: این زمانی اتفاق می‌افتد که یک معماری بسیار سفت و سخت و غیر قابل انعطاف باشد و افزودن ویژگی‌های جدید یا انطباق با نیازهای در حال تغییر را دشوار کند. به طور کلی باید ویژگی نرم بودن یک نرم‌افزار را همواره در نظر بگیریم و بدانیم یک نرم افزار باید در برابر توسعه و یا تغییر ویژگی همواره قابلیت انعطاف را داشته باشد.اگر تلاش کنی تمام مشتریان موجود را راضی نگهداری مطمئن باشید در انتهای کار هیچ یک راضی نخواهند بود.
خیلی ریزدانه شدن: یکی از ایرادات رایج معماری بیان ریزدانه معماری کلی نرم‌افزار است این موضوع خوب نیست زیرا در مرزهایی که تیم‌ها باهم کار می‌کنند این ریزدانگی‌ها مشکل ساز می شود پیشنهاد می‌شود خیلی ریز بیان نشود و بخش‌های ریز هر بخش به مسولین داخل هر تیم واگذار شود. بعدا به راحتی می‌شود موارد داخل تیم را بازسازی کرد زیاد نگران این موضوع نباشید. برخی از پارامتر‌های سازمان را با مسئولیت خودتان نادیده بگیرید. تغییرات بزرگ بسیار سخت تر از تغییرات داخل هر تیم است پس سعی کنید درشت دانه دسته بندی کنید تا مرزهای بین تیم‌ها شفاف تر باشد.
سیستم شما باید پویا باشد: دلیلی وجود ندارد تمام اتفاقات در معماری قرار گیرد به عنوان مثال اگر یک فیلد از دیتا دیاگرام تغییر کرد ثبت بشود باید مواردی که ضروری هستند در سند قرار بگیرند. نباید مسئولیت سیستم متمرکز باشد بلکه این یک کار تیمی است و باید با بقیه اعضا تیم مورد بررسی قرار گیرد. اگر کار سخت شده است و بسیار پیچیده باید راه دیگری پیدا کنید.اگر به کاری عادت کردید دلیل بر این نیست که این مسیر درست است.
معماری آزادانه: این مورد نیز اصلا خوب نیست و زمانی رخ می‌دهد که شما در معماری نرم افزار هیچگونه قیدی قرار ندهید و بدون ساختار نرم‌افزار را تولید کنید. نگهداری و پشتیبانی چنین معماری بسیار سخت است. در رویکرد میکروسرویس اگر قوانین و نحوه ارتباطات استاندارد نباشد شما یک ادغام بسیار ناکارآمد در بخش UI و frontend خواهید داشت. و frontend یک نقطه بحرانی پروژه خواهد شد. در بسیاری از موارد تنوع و استفاده از ابزارهای متنوع کار خوبی است ولی به شرط اینکه تمام این‌ها از قوانین معماری پیروی کنند نباید بگذارید هرج و مرج ایجاد شود. بین هرج و مرح و تنوع مرز باریکی وجود دارد که باید رعایت شود.
رشد سرطانی: سیستم‌های موفق از نظر کسب و کاری چون با یک توسعه ساده شروع می‌شوند و به مرور زمان تکامل پیدا می‌کنند لذا بسیار باید مراقب این موضوع باشند زیرا اگر یک مشکلی در ابتدا قرار گیرد تمام مواردی که در ادامه توسعه پیدا می‌کنند بر پایه مورد اول توسعه پیدا می‌کنند و ممکن است به یک معماری مشکل دار تبدیل شود به نوعی تکامل مدیریت نشده منجر به ایجاد هرج و مرج در سیستم خواهد شد. لذا از حاکمیت سبک معماری و محدودیت‌های آن نترسید و سعی کنید آن را رعایت کنید تا دچار هرج و مرج نشوید.
با هوش کمتر پیشرفت کنید: سخنران سه مدل مثال از شرکت‌های بزرگ می‌آورد و به کمک این سه مثال ما نکات زیر را برداشت می‌کنیم.
برای ایجاد معماری انعطاف‌پذیرتر و سازگارتر، از یک ریزمعماری با نقشه‌های اولیه استفاده کنید. به توسعه دهندگان نقشه هایی ارائه دهید تا به آنها کمک کند تا به سرعت اجزای جدید را ایجاد کنند. در صورت لزوم آماده باشید تا کد سفارشی را به یک راه حل منبع باز اضافه کنید.مطمئن شوید که معماری شما قابل توسعه و مستند است.
