حالت نقشه‌ی فنی فعال است — تصمیم‌های طراحی این سایت را ببینید

موضوع

مقاله‌های معماری

معماری نرم‌افزار به زبان تصمیم: لایه‌ها، مرزها، ثبت تصمیم و ساخت سامانه‌ای که بشود بعداً تغییرش داد.

۸ مقاله

معماری · ۳ دقیقه مطالعه

معماری نهایی از روز اول، پیاده‌سازی چابک در شروع

لازم نیست میان «سریع بسازیم» و «درست بسازیم» یکی را انتخاب کنید. اگر مرزهای سامانه از ابتدا درست کشیده شوند، می‌شود پشت هر مرز ساده‌ترین پیاده‌سازی را گذاشت و بعداً بدون بازنویسی رشد کرد.

خواندن مقاله
معماری · ۳ دقیقه مطالعه

لایه‌های قابل‌تعویض: چرا هر سرویس بیرونی باید پشت یک قرارداد باشد

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

خواندن مقاله
SaaS · ۳ دقیقه مطالعه

معماری چندمستاجری در SaaS: جداسازی داده‌ی مشتری‌ها

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

خواندن مقاله
معماری · ۳ دقیقه مطالعه

قرارداد API پیش از کد: چرا اول باید روی رابط توافق کنیم

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

خواندن مقاله
مهندسی · ۴ دقیقه مطالعه

امنیت از روز اول: حداقل‌هایی که هر محصول کوچک لازم دارد

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

خواندن مقاله