معماری تمیز در کتابها زیبا به نظر میرسد، اما اجرای بیچونوچرای آن در یک استارتاپ کوچک میتواند پروژه را زیر بار لایههای اضافی خفه کند. ایدهٔ اصلی ساده است: قواعد کسبوکار نباید به جزئیات فریمورک، پایگاه داده یا UI وابسته باشند. ما این اصل را نگه میداریم اما تعداد لایهها را با اندازهٔ واقعی پروژه تنظیم میکنیم.
در عمل، ما هستهٔ دامنه را در ماژولهایی مستقل از فریمورک نگه میداریم و دسترسی به داده را پشت اینترفیسهای Repository پنهان میکنیم. این کار وارونگی وابستگی را تضمین میکند؛ یعنی تغییر از PostgreSQL به یک سرویس بیرونی فقط یک پیادهسازی تازه میخواهد و منطق کسبوکار دستنخورده میماند. تست واحد هم بدون نیاز به بالا آوردن دیتابیس ممکن میشود.
بزرگترین خطا، انتزاع زودهنگام است. تا وقتی یک قابلیت واقعاً به چند پیادهسازی نیاز ندارد، ساختن اینترفیس برایش فقط بدهی شناختی اضافه میکند. ما قاعدهٔ «سه بار تکرار، بعد انتزاع» را به کار میبریم و اجازه میدهیم نیاز واقعی مرزها را آشکار کند، نه پیشبینیهای خوشبینانه.
نشانهٔ یک معماری سالم این است که توسعهدهندهٔ تازهوارد بتواند ظرف یک روز جای منطق هر قابلیت را حدس بزند. ما این را با ساختار پوشهبندی بر اساس فیچر، نامگذاری یکدست و یک سند کوتاه ADR برای هر تصمیم مهم تضمین میکنیم. معماری تمیز هدف نیست؛ ابزاری برای کاهش هزینهٔ تغییر در طول زمان است.