‏چرا ایجنت‌ها توی کدبیس قدیمی گم می‌شن

نویسنده می‌گه چند ساله داره توی کار روزمره‌ش از LLM استفاده می‌کنه و توی پروژه‌های کوچیک و تازه نتیجه عالیه. ولی تا پای کدبیس‌های چندساله وسط میاد، کیفیت کار مدل به‌شدت می‌افته. مثال خودش اینه: یه فیلد ساده مثل «وضعیت job offer» توی پروژه‌ی نو درست ساخته می‌شه، ولی توی سیستمی که چهار ساله داره کار می‌کنه، مدل چهارمین اسم رو برای مفهومی می‌سازه که از قبل سه تا اسم داشته.

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

نویسنده کار رو به دو نیمه تقسیم می‌کنه و واژه‌های strategic و tactical رو از کتاب A Philosophy of Software Design وام می‌گیره. کار strategic یعنی تصمیم‌گرفتن: خوندن سیستم و درآوردن اینکه چی باید عوض شه و چرا. کار tactical یعنی بردن همون تصمیم توی فایل‌ها. به گفته‌ی او هزینه‌ی تایپ‌کردن فرو ریخته ولی هزینه‌ی تصمیم‌گرفتن همون‌قدر بالا مونده، برای همین خودش توی نیمه‌ی اول کاملاً درگیره و توی نیمه‌ی دوم بیشتر نقش reviewer داره.

ستون فنی این آمادگی، DDD ـه. هر ریپو یه فایل .workflow.json توی ریشه داره که بلاک domain اش می‌گه پروژه چه bounded context هایی (یعنی مرزهایی که هر کدوم زبون و مدل خودشون رو دارن) داره و هر یال به همسایه چه شکلیه: to یعنی طرف مقابل، direction یعنی کی به کی زنگ می‌زنه، owner یعنی مدل کدوم طرف برنده‌ست و pattern یعنی خود رابطه. کنارش برای هر context یه CONTEXT.md هست؛ واژه‌نامه‌ی زنده با معنی دقیق هر اصطلاح و مترادف‌هایی که عمداً رد شدن.

هیچ سند دستی بالادستی وجود نداره: نقشه‌ی کل رو یه اسکریپت از روی همین بلاک‌ها می‌سازه، پس دورریختنی و دوباره‌ساختنیه. هر یال دو بار اعلام می‌شه، یه بار از هر طرف، و همین تکرار عمدیه: جنریتور جفت‌ها رو با یه جدول تطبیق چک می‌کنه و هر ناسازگاری رو به‌عنوان finding روی ریپوی مقصر به شکل ایشوی DDD ثبت می‌کنه. هر ایشو یه fingerprint داره تا اجرای دوباره ایشوی تکراری نسازه.

نکات کلیدی:

• بلاک domain توی .workflow.json تنها جای ثبت یه ریپوئه، پس رجیستری دومی نیست که از هم فاصله بگیره
• هر context یه CONTEXT.md داره که مترادف‌های عمداً ردشده رو هم نگه می‌داره
• CONTEXT-MAP.md دستی نوشته نمی‌شه؛ یه اسکریپت با راه‌رفتن روی همه‌ی ریپوها می‌سازتش
• هر یال از دو طرف اعلام می‌شه و ناسازگاری‌ها خودکار به ایشوی DDD با fingerprint تبدیل می‌شن
• توی پروژه‌ی نمونه job-offer-box، بک‌اند Rust مالک واژه‌های محصوله و ریپوی وب فقط واژه‌های صفحه (View Model، Filter State، Facet Stats) رو داره