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

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

تیم تصمیم گرفته بود «معماری تمیز» را جدی‌تر وارد پروژه کند. چند پوشه‌ی تازه ساخته شد: entity، usecase و adapter. نمودار دایره‌ای معروف هم در جلسه‌ی فنی روی تخته کشیده شد. از بیرون، همه‌چیز شبیه یک حرکت درست به نظر می‌رسید: نام‌ها آشنا بودند، ساختار پروژه مرتب‌تر شده بود و کدها دیگر همگی در یک پوشه‌ی بزرگ کنار هم نبودند.

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

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

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

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

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

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