مرزهای مسئولیت در معماری نرم‌افزار

مرزهای مسئولیت در معماری نرم‌افزار: از ابهام تا قراردادِ قابل‌راستی‌آزمایی

**نویسنده: سهیل مظفری**

مسئله: وقتی کارِ موازی، مالکیت را مبهم می‌کند

معماری نرم‌افزار فقط انتخاب ساختار یا فناوری نیست؛ بخشی از آن روشن‌کردن این پرسش است که هر جزء، تیم یا نقش دقیقاً در برابر چه چیزی مسئول است و کجا مسئولیتش پایان می‌یابد. در کارِ موازی، چند جریان توسعه می‌توانند هم‌زمان بر یک سامانه اثر بگذارند. اگر مرز مسئولیت میان این جریان‌ها روشن نباشد، تشخیص منشأ یک تغییر، انتظار از جزء دیگر، یا معیار پذیرشِ خروجی دشوار می‌شود. مسئله در اینجا صرفاً «تقسیم کار» نیست؛ مسئله، تعریف رابطه‌ای است که اجزا را به هم متصل و در عین حال از هم متمایز می‌کند.

**BOUND**، کوتاه‌شدهٔ *Boundary-Oriented Unified Development*، رویکردی برای پرداختن به ابهامِ مرزهای مسئولیت در کارِ موازیِ نرم‌افزار است. این رویکرد برای تیم‌های انسانی و نیز تیم‌هایی که از کمک هوش مصنوعی استفاده می‌کنند قابل استفاده است، اما به هوش مصنوعی محدود یا وابسته نیست. ارزش تحلیلی آن در این است که پیش از تبدیل یک انتظار به اجرای فنی، محل و حدود مسئولیت را موضوع گفت‌وگو و تصمیم معماری قرار می‌دهد.

واژگان BOUND برای صورت‌بندی مسئولیت

BOUND پنج عنصر **Domain، Boundary، Contract، Execution** و **Verification** را در یک زنجیرهٔ فکری کنار هم قرار می‌دهد. در این مقاله، Domain به حوزهٔ مسئله‌ای اشاره دارد که قرار است دربارهٔ آن تصمیم گرفته شود؛ Boundary به جداییِ مسئولیت‌ها و نقطهٔ تماس میان آن‌ها؛ Contract به توافقی که انتظارهای متقابل را بیان می‌کند؛ Execution به تحقق آن توافق در کار اجرایی؛ و Verification به بررسی سازگاری خروجی با آن توافق. این ترتیب، مسئولیت را نه یک برچسبِ مبهم، بلکه موضوعی قابل بیان و قابل بررسی می‌سازد.

آغاز از Domain اهمیت دارد، زیرا نام‌گذاری یک مؤلفه یا سپردن یک وظیفه بدون روشن‌بودن حوزهٔ مسئله، می‌تواند مرزی ظاهراً دقیق اما نامرتبط ایجاد کند. سپس Boundary پرسش‌های معماری را متمرکز می‌کند: چه چیزی درون این مسئولیت است، چه چیزی بیرون آن قرار می‌گیرد، و تعامل با مسئولیت مجاور از کدام نقطه انجام می‌شود؟ پاسخ به این پرسش‌ها نباید به برداشت ضمنی افراد واگذار شود؛ زیرا برداشت ضمنی در کار موازی به‌سادگی ناهمسان می‌شود.

مرز پیش از قرارداد

قرارداد زمانی مفید است که طرف‌ها و قلمرو آن معلوم باشند. اگر ابتدا مرز مشخص نشود، قرارداد ممکن است جزئیات اجرایی را ثبت کند، بی‌آنکه روشن کند کدام طرف صاحب هر تصمیم یا تغییر است. در BOUND، قرارگرفتن **Domain → Boundary** پیش از Contract به این معناست که قرارداد بر بستری از حوزه و مرز نوشته می‌شود. بنابراین، قرارداد فقط فهرستی از درخواست‌ها یا پاسخ‌ها نیست؛ بیانِ یک انتظار میان مسئولیت‌های تعریف‌شده است.

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

از قرارداد تا اجرا و راستی‌آزمایی

پس از Contract، دو مرحلهٔ **Execution** و **Verification** قرار می‌گیرند. Execution به انجام کار بر پایهٔ قرارداد مربوط است، نه جایگزین‌کردن قرارداد با فرض‌های تازه در هنگام پیاده‌سازی. Verification نیز بازگشت به همان انتظارِ توافق‌شده است تا پرسش بررسی روشن بماند: آیا خروجی با قرارداد سازگار است؟ این توالی، میان «انجام‌شدن کار» و «تأییدشدن سازگاری آن» تمایز می‌گذارد.

برای معماری، این تمایز یک احتیاط عملی است. اجرای موفق از منظر یک جزء، به‌تنهایی نشان نمی‌دهد که تعامل آن جزء با مسئولیت‌های دیگر درست صورت گرفته است. راستی‌آزماییِ مبتنی بر قرارداد، بررسی را به رابطهٔ میان مرزها پیوند می‌دهد. در تیم‌های دارای کمک هوش مصنوعی نیز همین اصل برقرار است: ابزار یا عامل می‌تواند در تولید یا بررسی اثر داشته باشد، اما مرز، قرارداد و معیار راستی‌آزمایی همچنان باید صریح باشند.

نسبت BOUND با IFEM

**IFEM** یا *Interface-First Execution Methodology* توالی **Interface → Contract → Execution → Verification** را بیان می‌کند. BOUND این توالی را با افزودن **Domain → Boundary** پیش از Contract گسترش می‌دهد. از این رو، تمایز اصلی در این مقاله ساده است: IFEM از Interface آغاز می‌کند، در حالی که BOUND پیش از قرارداد، حوزه و مرز مسئولیت را وارد صورت‌بندی می‌کند. این تفاوت را نباید به ادعای برتریِ کلی یکی بر دیگری تبدیل کرد؛ هر دو نامِ روش‌شناختی و توالی‌های مشخص خود را دارند.

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

نتیجه‌گیری

مرز مسئولیت، عنصر حاشیه‌ای معماری نیست؛ شرط فهم‌پذیرشدن قراردادها و ارزیابی تعامل‌ها در کار موازی است. BOUND با توالی **Domain → Boundary → Contract → Execution → Verification** چارچوبی برای بیان این مسئله فراهم می‌کند و در کنار IFEM، تفاوت آغاز از مرز با آغاز از رابط را روشن می‌سازد. کاربرد محتاطانهٔ این واژگان می‌تواند گفت‌وگو دربارهٔ مسئولیت را از فرض‌های ضمنی به انتظارهای صریح و قابل‌راستی‌آزمایی منتقل کند.

منابع

[1] مظفری، سهیل. **BOUND: Boundary-Oriented Unified Development**. DOI: [10.5281/zenodo.22257583](https://doi.org/10.5281/zenodo.22257583).

[2] مظفری، سهیل. **IFEM: Interface-First Execution Methodology**. DOI: [10.5281/zenodo.20621561](https://doi.org/10.5281/zenodo.20621561).