معماری نهایی از روز اول، پیاده‌سازی چابک در شروع
لازم نیست میان «سریع بسازیم» و «درست بسازیم» یکی را انتخاب کنید. اگر مرزهای سامانه از ابتدا درست کشیده شوند، می‌شود پشت هر مرز ساده‌ترین پیاده‌سازی را گذاشت و بعداً بدون بازنویسی رشد کرد.
در شروع هر محصول، دو صدا شنیده می‌شود. یکی می‌گوید: «فعلاً سریع بسازیم، بعداً درستش می‌کنیم.» دیگری می‌گوید: «باید از اول برای مقیاس بزرگ طراحی کنیم.» هر دو، اگر تنها شنیده شوند، پرهزینه‌اند. اولی به بازنویسی می‌رسد و دومی به محصولی که هیچ‌وقت منتشر نمی‌شود.
اصل کاری من راه سومی است: معماری نهایی از روز اول، پیاده‌سازی چابک در شروع.
این اصل دقیقاً یعنی چه
معماری یعنی مرزها: کدام بخش مسئول چه چیزی است و بخش‌ها چطور با هم حرف می‌زنند. پیاده‌سازی یعنی آنچه پشت هر مرز قرار دارد.
مرزها را تغییر دادن گران است، چون همه‌ی بخش‌ها به آن‌ها تکیه کرده‌اند. پیاده‌سازی پشت یک مرز را تغییر دادن ارزان است، چون بقیه‌ی سامانه از آن خبر ندارد.
پس چیزی که باید از روز اول درست باشد مرزهاست، نه حجم کد.
یک مثال ساده: ارسال اعلان
فرض کنید محصول شما باید هنگام ثبت سفارش به مدیر خبر بدهد. در نسخه‌ی اول، شاید فقط یک پیام در لاگ کافی باشد. بعداً پیامک، بعد ایمیل، بعد پیام‌رسان.
اگر کد ثبت سفارش مستقیماً سرویس پیامک را صدا بزند، هر تغییر یعنی دست بردن در منطق اصلی. اما اگر از ابتدا یک قرارداد ساده داشته باشید، مثل notifyNewOrder(order)، منطق اصلی فقط همین را می‌شناسد. پشت آن امروز یک خط لاگ است و فردا سه کانال هم‌زمان.
همین سایت با همین الگو ساخته شده است: فرم تماس فقط یک «اعلان‌دهنده» را می‌شناسد و اینکه پیام به کجا می‌رود با تنظیمات تعیین می‌شود، نه با تغییر کد. جزئیات فنی این الگو را در لایه‌های قابل‌تعویض نوشته‌ام.
چه چیزهایی باید از روز اول درست باشند
- مرز ماژول‌ها. هر بخش مسئولیت روشن و رابط مشخص داشته باشد.
- مدل داده‌ی اصلی. موجودیت‌های کلیدی و رابطه‌هایشان. تغییر این‌ها بعداً یعنی مهاجرت داده.
- مرز با سرویس‌های بیرونی. پرداخت، پیامک، هوش مصنوعی و ذخیره‌سازی پشت لایه‌ی خودشان.
- هویت و دسترسی. اضافه کردن امنیت به سامانه‌ای که بدون آن طراحی شده، بازنویسی است. در این باره امنیت از روز اول را ببینید.
- مسیر استقرار. از روز اول باید بشود محصول را به شکل تکرارپذیر منتشر کرد.
چه چیزهایی می‌توانند ساده شروع شوند
- پایگاه داده‌ی سبک به جای خوشه‌ی توزیع‌شده.
- یک سرور به جای ده سرویس جدا.
- کار دستی پشت صحنه به جای اتوماسیون کامل.
- یک روش پرداخت، یک زبان، یک کانال.
هیچ‌کدام از این‌ها بدهی فنی نیستند، به شرطی که پشت مرز درست قرار گرفته باشند. بدهی فنی وقتی ساخته می‌شود که ساده‌سازی، مرزها را هم خراب کند.
چرا این روش برای کارفرما مهم است
این اصل یک نتیجه‌ی تجاری مشخص دارد: نسخه‌ی اول زود می‌رسد، و هزینه‌ای که برای آن داده‌اید در نسخه‌ی دوم دور ریخته نمی‌شود. محصولی که امروز اجرا می‌شود، سال‌ها بعد هم قابل رشد است.
تصمیم‌هایی که در این مسیر گرفته می‌شوند باید مکتوب بمانند تا بعداً قابل‌دفاع باشند. ابزار این کار ثبت تصمیم‌های معماری است.
جمع‌بندی
سرعت و کیفیت دشمن هم نیستند. آنچه آن‌ها را آشتی می‌دهد، تشخیص این است که کدام بخش باید از ابتدا درست باشد و کدام بخش می‌تواند ساده شروع شود. مرزها ثابت، پیاده‌سازی سبک.
اگر پیش از شروع ساخت به نقشه‌ی دقیق نیاز دارید، معماری و برنامه‌ریزی فنی همین خروجی را می‌دهد.