آیا معماری نرم‌افزار شما "فریاد میزنه"؟ 📢😲
وقتی به نقشه ی یک خونه نگاه میکنیم اولین المان هایی که توجه مارو جلب میکنن آشپزخونه، حیاط، اتاق خواب و این چیزاست. نقشه یه کتابخونه هم با محوطه، لابی، قفسه‌ها و سالن مطالعه همین حس رو داره. به عبارتی، نقشه یه ساختمونخودش داره داد میزنه که چیه!
تو دنیای نرم‌افزار هم معماری سیستم باید هدف کسب‌وکار رو فریاد بزنه، نه اینکه توی انبوهی از ابزار و تکنولوژی گم بشه!
وقتی کد یه پروژه رو می‌بینیم، باید سریع بفهمیم "این سیستم چیکار می‌کنه"، نه اینکه از چه فناوری‌هایی استفاده کرده🤕
به نظر من این رویکرد میتونه یه معیار شفاف برای ساختار پروژه ها باشه: فولدربندی بر اساس دامین یا فیچرها باشن، نه کنترلر و ریپازیتوری و چیزای تکنیکال.
یکی دیگه از نشانه های معماری خوب اینه که اجازه بده انتخاب تکنولوژی های از قبیل دیتابیس و وب سرور و حتی فریم ورک رو به تعویق بندازیم و روی یوزکیس هامون تمرکز کنیم. طبعا اینکار منجر به تست پذیری بهتر معماری میشه.
وقتی یونیت تست های ما مستقل از مکانیزم دلیوری، فریم ورک، دیتابیس و تکنولوژی های دیگه باشند، تغییر اون تکنولوژی و ابزار ها تاثیر زیادی بر منطق اصلی بیزینس ما نخواهد داشت.
یادمون باشه حتی تحت وب بودن یک پروژه صرفا یک مکانیزم دلیوری هست و هیچ ارتباطی با منطق بیزینسی ما نداره. اگر قرار باشه یک اپلیکیشن کنسول هم به پروژه اضافه کنیم، باید خیالمون راحت باشه که منطق بیزینسی ما قبلا تست شده و صرفا یک لایه دلیوری دیگه به پروژه اضافه کردیم.
توسعه ی فریم ورک محور یا تاکید بیجا روی ابعاد تکنیکال مثل ابزار ها و پاردایم ها ( کنترلر و ریپازیتوری و...) یا حتی تاکید روی استایل معماری هایی مثل هگزاگونال (پورت و اداپتر و ...) و یا استفاده نادرست از دیزاین پترن ها هم میتونه باعث بشه معماری ما شفاف نباشه و فریاد نزنه :)
این هم لینک مقاله اصلی
https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
