چگونه مرز بین منطق دامنه و زیرساخت در پروژههای بزرگ از بین میرود؟
در پروژههای نرمافزاری بزرگ، یکی از مهمترین اصول طراحی که تقریباً همه دربارهاش صحبت میکنند اما در عمل بهسختی رعایت میشود، تفکیک منطق دامنه از زیرساخت است. روی کاغذ همه چیز ساده است؛ منطق دامنه باید مستقل از دیتابیس، فریمورک، شبکه و ابزارهای جانبی باشد، اما وقتی پروژه رشد میکند، تیم بزرگ میشود و فشار تحویل بالا میرود، این مرز کمکم محو میشود. نتیجه هم سیستمی است که تغییر دادن، تست کردن و توسعه دادنش هر روز سختتر از دیروز میشود. در این مطلب میخواهیم خیلی واقعی و بدون شعار بررسی کنیم که چرا این اتفاق میافتد و چه عواملی باعث فروپاشی این مرز حیاتی میشوند.
منطق دامنه و زیرساخت دقیقاً چه تفاوتی دارند؟
منطق دامنه همان بخش از سیستم است که قوانین اصلی کسبوکار را پیادهسازی میکند؛ یعنی پاسخ به این سؤال که «سیستم چه کاری باید انجام دهد». این بخش نباید بداند دیتا کجا ذخیره میشود، با چه پروتکلی ارسال میشود یا روی چه دیتابیسی نشسته است. در مقابل، زیرساخت شامل دیتابیس، پیامرسانها، APIها، فایل سیستم، کش، فریمورکها و هر چیزی است که فقط وسیله اجراست نه هدف. مشکل از جایی شروع میشود که این دو بهجای همکاری از پشت مرز مشخص، شروع میکنند به نفوذ در قلمرو همدیگر. وقتی منطق دامنه مستقیماً با ORM، کوئری SQL یا API خارجی حرف میزند، یعنی این مرز عملاً شکسته شده است.
فشار زمان و تحویل سریع، اولین ضربه به مرزها
در پروژههای واقعی، مخصوصاً استارتاپی یا محصولاتی که بازار رقابتی دارند، همیشه فشار زمان وجود دارد. تیم میخواهد سریع فیچر بدهد، باگ را ببندد و ددلاین را رد نکند. در این شرایط، تفکیک لایهها اولین چیزی است که قربانی میشود. بهجای طراحی تمیز، یک کوئری مستقیم داخل منطق بیزینس نوشته میشود یا یک سرویس دامنه مستقیماً به فریمورک وابسته میشود. این تصمیمها شاید در لحظه منطقی باشند، اما وقتی چند ماه میگذرد، تبدیل به الگوی تکرارشونده میشوند و کل سیستم را درگیر میکنند. هر تصمیم کوچک عجولانه، یک ترک ریز در دیوار بین دامنه و زیرساخت ایجاد میکند.
وابستگی به فریمورکها، قاتل خاموش استقلال دامنه
بسیاری از فریمورکها طوری طراحی شدهاند که استفاده نکردن از آنها سختتر از استفاده کردن است. Annotationها، Decoratorها، Active Recordها و امکانات جادویی باعث میشوند منطق دامنه بهصورت ناخواسته به فریمورک قفل شود. وقتی یک Entity دامنه پر از annotation دیتابیس است یا منطق بیزینس داخل مدل ORM نوشته میشود، دیگر نمیتوان گفت این لایه مستقل است. مشکل اینجاست که تیم معمولاً متوجه عمق این وابستگی نمیشود تا زمانی که بخواهد دیتابیس را عوض کند، تستهای سریع بنویسد یا بخشی از سیستم را جداگانه اجرا کند. آنوقت است که هزینه واقعی این وابستگی خودش را نشان میدهد.
تستناپذیری، نشانهای واضح از فروپاشی مرزها
یکی از بهترین راهها برای تشخیص اینکه مرز بین دامنه و زیرساخت از بین رفته یا نه، نگاه کردن به تستهاست. اگر برای تست کردن یک قانون ساده بیزینسی مجبور هستید دیتابیس بالا بیاورید، کانفیگ شبکه تنظیم کنید یا mockهای عجیب بسازید، یعنی دامنه شما آلوده شده است. منطق دامنه سالم باید بتواند با تستهای سریع و ساده اجرا شود، بدون اینکه بداند بیرون از خودش چه خبر است. وقتی تستها سنگین، کند و شکننده میشوند، این فقط مشکل تست نیست؛ این علامت یک طراحی اشتباه در لایهبندی سیستم است.
رشد تیم و ناهماهنگی تصمیمها
هرچه تیم بزرگتر میشود، احتمال شکستن مرزها بیشتر میشود. توسعهدهندگان مختلف با سطح تجربه متفاوت وارد پروژه میشوند و هرکدام برداشت خودش را از معماری دارد. اگر اصول طراحی بهوضوح مستند نشده باشند یا بازبینی کد جدی وجود نداشته باشد، هر نفر ممکن است کمی منطق دامنه را به زیرساخت نزدیکتر کند. این تغییرات کوچک بهمرور انباشته میشوند و یک روز بیدار میشوید و میبینید دیگر لایه مشخصی وجود ندارد. سیستم به مجموعهای از کلاسها تبدیل میشود که هم بیزینس را میدانند، هم دیتابیس را، هم شبکه را.
تصمیمهای موقت که دائمی میشوند
خیلی از آلودگیهای معماری با یک جمله ساده شروع میشوند: «فعلاً اینطوری بنویسیم، بعداً درستش میکنیم». این بعداً تقریباً هیچوقت نمیرسد. کدی که بهصورت موقت نوشته شده، بهسرعت وارد مسیر اصلی سیستم میشود و بقیه هم روی آن کد مینویسند. بعد از مدتی تغییر دادن آن به معنی بازنویسی بخش بزرگی از سیستم است. اینجاست که مرز بین دامنه و زیرساخت نه با یک تصمیم بزرگ، بلکه با صدها تصمیم کوچک موقت از بین میرود.
چگونه میتوان جلوی این فروپاشی را گرفت؟
اولین قدم، پذیرش این واقعیت است که تفکیک دامنه و زیرساخت یک کار یکباره نیست، بلکه یک فرآیند دائمی است. باید در بازبینی کد، طراحی فیچرهای جدید و حتی ریفکتورهای کوچک، همیشه این سؤال پرسیده شود که «آیا این کد واقعاً متعلق به دامنه است یا زیرساخت؟». استفاده از الگوهایی مثل Dependency Inversion، Ports and Adapters یا Clean Architecture کمک میکند، اما فقط وقتی که تیم واقعاً به فلسفه پشت آنها پایبند باشد. ابزار بدون طرز فکر درست، فقط ظاهر معماری را زیبا میکند، نه باطنش را.
مرزها را باید آگاهانه حفظ کرد
از بین رفتن مرز بین منطق دامنه و زیرساخت یک اتفاق ناگهانی نیست، بلکه نتیجه طبیعی بیتوجهیهای کوچک و مداوم است. فشار زمان، وابستگی به فریمورک، رشد تیم و تصمیمهای موقت، همگی دست به دست هم میدهند تا این مرز محو شود. پروژههایی که این مرز را حفظ میکنند، الزاماً کد کمتری ندارند، بلکه آگاهانهتر تصمیم میگیرند. اگر سیستم قرار است سالها زنده بماند، این مرز نه یک تجمل معماری، بلکه یک ضرورت حیاتی است.
