نظریه معماری زمانی ملموس میشود که ردِ درخواستی واقعی را در آن دنبال کنیم. در این نوشته، نمونهای گویا را گامبهگام بررسی میکنیم: پیام مبهم کاربری که باید به اقدامی مشخص و ساختاریافته تبدیل شود. این سناریو فرضی و کلی است، اما الگویی را به تصویر میکشد که در بسیاری از سامانههای چندعاملی تکرار میشود.
درخواست: پیامی بدون ساختار
فرض کنید کاربری چنین پیامی میفرستد: «سفارشی که هفته پیش ثبت کردم هنوز نرسیده و کسی هم پاسخگو نیست.» درک این پیام برای انسان آسان است، اما برای سامانه چیزی جز یک متن آزاد و بدون ساختار نیست. وظیفه سامانه این است که از دل این جمله، نیت کاربر، جزئیات لازم و اقدام مناسب را استخراج کند.
گام ۱: درک نیت کاربر در لایه پیشزمینه
نخستین مؤلفهای که با پیام مواجه میشود، متخصص گفتوگو در لایه پیشزمینه است. کار او درک زبان طبیعی و هدایت گفتوگوست: متوجه میشود که پیام دریافتی، شکایتی درباره تأخیر در ارسال سفارش است و اگر اطلاعاتی ناقص باشد — مثلاً شماره سفارش — آن را از کاربر میپرسد. این لایه عمیقاً وارد منطق حوزه نمیشود؛ بلکه فقط نیت کاربر را مشخص میسازد و دادههای اولیه کافی را جمعآوری میکند.
گام ۲: واگذاری کار به سرویس حوزه
پس از روشن شدن نیت، متخصص گفتوگو کار را به سرویس تخصصی حوزه در لایه پسزمینه واگذار میکند. این انتقال به شکل مستقیم انجام نمیشود، بلکه از الگوی رویدادمحور پیروی میکند: رویدادی با این مضمون که «شکایتی مبنی بر تأخیر آماده بررسی است» منتشر میشود که صرفاً حاوی یک شناسه است. سرویس حوزه این رویداد را دریافت میکند و وضعیت کامل را از حافظه مشترک — و نه از خود رویداد — میخواند.
گام ۳: پردازش شناختی سنگین
اکنون سرویس حوزه وظیفه اصلی را بر عهده میگیرد و به پیام ساختار مشخصی میدهد. این سرویس نوع مسئله را تعیین میکند (تأخیر در تحویل)، اولویت آن را تخمین میزند و اقدام مناسب را انتخاب میکند — برای مثال، ایجاد تیکت پیگیری با تمام فیلدهای لازم. این مرحله دقیقاً همان جایی است که به تخصص بالایی نیاز دارد و به همین دلیل، از لایه گفتوگو مجزا شده است.
گام ۴: تصمیمگیری برای گام بعدی توسط ناظر
با اتمام کار سرویس حوزه، رویدادی تحت عنوان «انجام شد» منتشر میشود. ناظر تکمیل این رویداد را دریافت میکند، وضعیت را از حافظه میخواند و تصمیمی قطعی میگیرد: آیا کار دیگری باقی مانده است یا زمان پاسخدهی به کاربر فرا رسیده؟ در این مثال، تیکت صادر شده و کار دیگری باقی نمانده است؛ در نتیجه، ناظر به لایه گفتوگو اطلاع میدهد که پاسخ مقتضی را آماده کند.
گام ۵: پاسخدهی به کاربر
در نهایت، متخصص گفتوگو چرخه را کامل میکند و پاسخی شفاف و با لحنی انسانی به کاربر میدهد: «شکایت شما ثبت شد، شماره پیگیری فلان است و تا فلان زمان رسیدگی میشود.» کاربر تنها گفتوگویی ساده را تجربه کرده است، اما پشت صحنه، پیام مبهم او از چندین لایه تخصصی عبور کرده تا به اقدامی ساختاریافته تبدیل شود.
آنچه این مسیر به ما نشان میدهد
این مسیر سه اصل کلیدی در معماری را آشکار میسازد. نخست، تفکیک لایهها: مدیریت گفتوگو در پیشزمینه و انجام پردازشهای شناختی سنگین در پسزمینه. دوم، رویداد به عنوان محرک: اجزای مختلف به جای انتقال دادههای حجیم، از طریق شناسهها به یکدیگر متصل میشوند و مرجع اطلاعات همیشه حافظه مشترک است. سوم، تصمیمگیری قطعی در نقاط کلیدی برای جلوگیری از تضعیف هماهنگی میان بخشها. رعایت همین چند اصل ساده، تفاوت میان سامانهای را رقم میزند که پیامی مبهم را با اطمینان تا رسیدن به نتیجه هدایت میکند، با سامانهای که در مواجهه با نخستین اتفاق غیرمنتظره از کار میافتد.