معماری MaMa-CRM در قالب arc42

در ادامهٔ مجموعه مقالات ما دربارهٔ مستندسازی معماری با الگوی arc42، اینبار به سراغ یکی از مهمترین و پیچیدهترین مثالها میرویم: سیستم MaMa-CRM؛ سامانهای واقعی، عملیاتی و بزرگ که در دنیای کسبوکارهای انبوه (Mass Market) بهکار گرفته میشود.

MaMa-CRM برای سازمانهایی طراحی شده که روزانه با میلیونها مشتری سر و کار دارند؛
سازمانهایی مثل:

شرکتهای بیمه
اپراتورهای تلفن همراه
ارائهدهندگان خدمات انرژی و آب
بانکها و شرکتهای کارت اعتباری
شرکتهای بزرگ مدیریت املاک

در چنین بازارهایی، ارتباط با مشتری معمولاً گسترده، تکرارشونده و در مقیاس بسیار بزرگ است. در بسیاری از این صنایع، این ارتباطها سالها روی کاغذ مدیریت میشد. وظیفهٔ MaMa-CRM این بود که این بار سنگین را از دوش سازمانها بردارد و بهصورت دیجیتال و خودکار مدیریت کند.

جالبتر اینکه MaMa-CRM ابتدا برای یک پروژهٔ بسیار مهم و حساس ساخته شد:
پشتیبانی از راهاندازی “کارت سلامت الکترونیک آلمان”.
بعدها همین پلتفرم در کمپینهایی مثل صدور قبوض تلفن، قرائت کنتور برق، مدیریت اطلاعات مشترکین و موارد مشابه نیز استفاده شد.

یکی از ویژگیهای منحصربهفرد این سیستم این است که:

برای هر مشتری سازمانی (Mandator)، یک نسخه کاملاً مستقل و جداگانه از MaMa-CRM اجرا میشود.

این استقلال باعث میشود هر سازمان بتواند بهصورت اختصاصی، با پیکربندی مخصوص خود و برای کمپینهای خاص خود از سیستم استفاده کند. همین نیاز به انعطافپذیری عمیق موجب شد تصمیمات معماری مهمی در طراحی MaMa-CRM گرفته شود—و این مثال را به یک نمونه ایدهآل برای آموزش arc42 تبدیل میکند.

تیم توسعهٔ MaMa-CRM شامل ۷ تا ۱۰ نفر بود که طی ۱۵ ماه، در اسپرینتهای ۲ تا ۴ هفتهای روی این پروژه کار کردند.
خود گرنوت استارکه (نویسندهٔ arc42) یکی از اعضای اصلی این تیم بوده و اجازه یافته دربارهٔ این سیستم صحبت کند—البته بدون افشای نام شرکت.

در این مقاله، ما قصد داریم:

معماری سیستم MaMa-CRM را از زاویهٔ الگوی arc42 بررسی کنیم
نیازمندیهای کلیدی و چالشهای طراحی را تحلیل کنیم
و ببینیم چگونه یک سیستم واقعی در دنیای کسبوکارهای انبوه میتواند از مستندسازی معماری بهره ببرد

این مثال، برخلاف HSC، کاملاً صنعتی، بزرگ و چندلایه است؛
به همین دلیل، بهترین نمونه برای یادگیری معماری سیستمهای واقعی محسوب میشود.

III.1 مقدمه و اهداف سیستم MaMa-CRM

سیستم MaMa-CRM یک پلتفرم نرمافزاری گسترده و انعطافپذیر است که برای مدیریت و هماهنگی فرآیندهای ارتباط با مشتری در کسبوکارهای انبوه طراحی شده است؛ کسبوکارهایی که میلیونها مشتری دارند و تعاملات روزانهشان آنقدر زیاد است که مدیریت آنها بهصورت دستی یا کاغذی کاملاً غیرواقعی و پرخطا میشود.

این پلتفرم بهگونهای ساخته شده که بتواند برای صنایع مختلف، با نیازهای کاملاً متفاوت، پیکربندی شود—بدون آنکه نیاز به تغییر کد داشته باشد. همین موضوع، MaMa-CRM را از یک «سامانهٔ ساده» به یک خانوادهٔ محصول (Product Family) تبدیل میکند؛ سیستمی که هستهٔ مشترک دارد، اما هر مشتری سازمانی میتواند نسخهٔ اختصاصی خود را دریافت کند.

MaMa-CRM توسط چه سازمانی توسعه و راهبری میشود؟

این سیستم توسط یک دیتاسنتر نوآور (که در این متن “InDAC” نامگذاری شده) ساخته و پشتیبانی شده است—شرکتی که خدمات نرمافزاری مدیریتشده (Hosted Services) برای سازمانهای بزرگ ارائه میدهد.
InDAC بهعنوان پیمانکار، برای هر یک از mandatorها (سازمان مشتری) یک نسخهٔ مستقل از MaMa-CRM را اجرا و عملیاتی میکند.

مسئلهای که MaMa-CRM حل میکند چیست؟

کسبوکارهای انبوه—مانند بیمه، مخابرات، بانکداری و مدیریت انرژی—نمیتوانند ارتباطات مشتری را بهصورت دستی مدیریت کنند.
این ارتباطات شامل:

ارسال پیشنهادهای جدید
اطلاعرسانی تغییرات قرارداد
دریافت بازخورد مشتری
جمعآوری اسناد یا تأییدیهها
پیگیری وضعیت ارتباطات

است و معمولاً از چندین کانال مختلف انجام میشود:
ایمیل، پیامک، تماس تلفنی، فکس، نامه، یا حتی مراجعه حضوری.

بدون یک سیستم متمرکز، این ارتباطات:

گم میشوند
خطا دارند
قابل نظارت نیستند
و کیفیت خدمات بهشدت افت میکند

MaMa-CRM برای حل همین مشکل طراحی شده است.

چند مثال واقعی از استفادهٔ MaMa-CRM

برای درک بهتر دامنهٔ سیستم، چند نمونه از کمپینهای رایج که MaMa-CRM پشتیبانی میکند را مرور میکنیم:

۱) مدیریت تغییرات قرارداد و تعرفههای جدید (Telecom، Insurance، ISP)

مثلاً:
اپراتور تلفن همراه یک طرح جدید ارائه میدهد و مشتریان باید تأیید کنند، سؤال بپرسند یا نظرشان را اعلام کنند.
MaMa-CRM تمام این تعاملات را ساماندهی میکند.

۲) ارسال صورتحساب و رسیدگی به پشتیبانی (Call-by-call Providers)

Mandator دادههای صورتحساب را به MaMa ارسال میکند و سیستم:

چاپ قبضها
ارسال آنها
و مدیریت درخواستهای پشتیبانی

را هماهنگ میکند.
(تسویه حساب مالی خارج از محدودهٔ سیستم است.)

۳) مدیریت عکسهای کارتها (Credit Cards، Insurance، e-Health Card)

در برخی سیستمها، عکس مشتری باید روی کارت چاپ شود.
MaMa-CRM مدیریت ذخیره، پردازش و تخصیص این تصاویر را انجام میدهد.

۴) قرائت کنتور برق، آب یا گاز

شرکتهای انرژی یا املاک از MaMa-CRM برای:

جمعآوری داده
پیگیری وضعیت
و مدیریت چرخهٔ ارتباط با مشتریان

استفاده میکنند.

تمرکز اصلی معماری MaMa-CRM: انعطافپذیری شدید

از آنجا که MaMa-CRM قرار است برای صنایع مختلف، با ورودیها، خروجیها، کانالها و فرآیندهای کاملاً متفاوت استفاده شود، یک الزام کلیدی وجود دارد:

سیستم باید بدون تغییر کد، برای هر mandator و هر کمپین قابل پیکربندی باشد.

این نیاز معماری را بهشدت تحت تأثیر قرار داده و باعث شده طراحی سیستم بر پایهٔ موارد زیر انجام شود:

جداسازی کامل هستهٔ سیستم از اجزای پیکربندیشونده
پشتیبانی از کانالهای مختلف ارتباطی
پشتیبانی از مدلهای مختلف داده
پشتیبانی از انواع متفاوت فرآیندهای کاری
اجرای نسخههای کاملاً مستقل برای هر mandator

این نیازمندیها بسیاری از تصمیمات معماری مهم را شکل دادهاند که در بخشهای بعدی arc42 به آنها خواهیم پرداخت.

III.1.1 – مرور نیازمندیها Requirements Overview

MaMa-CRM یک سیستم بسیار انعطافپذیر و چندمنظوره است که برای پشتیبانی از کمپینهای CRM در مقیاس انبوه طراحی شده.
در این سیستم، سازمانهایی مانند:

اپراتورهای تلفن همراه
شرکتهای بیمه
ارائهدهندگان اینترنت
شرکتهای انرژی و آب
و حتی مؤسسات مدیریت املاک

نقش «Mandator» یا مشتری سازمانی را دارند.

این سازمانها بخشی از فرآیندهای ارتباط با مشتریشان را به شرکت InDAC واگذار میکنند، و InDAC با استفاده از MaMa-CRM آنها را بهصورت حرفهای اجرا و مدیریت میکند.

به بیان سادهتر:

MaMa-CRM، مغز عملیاتی کمپینهای بزرگ ارتباط با مشتری است.

و باید بتواند با سازمانهایی کار کند که میلیونها مشتری دارند و تعاملاتشان از دهها مسیر مختلف وارد سیستم میشود.

کمپینهایی که MaMa-CRM باید پشتیبانی کند

برای اینکه MaMa-CRM یک پلتفرم واقعی و صنعتی باشد، باید بتواند چند نوع کمپین CRM را بدون تغییر کد، تنها با پیکربندی پشتیبانی کند. برخی از مهمترین سناریوها عبارتاند از:

۱) تغییر تعرفه یا بهروزرسانی قراردادها

در صنایع مانند بیمه، مخابرات، اینترنت یا انرژی، قراردادها و تعرفهها دائماً تغییر میکنند.
ماجرا گاهی ساده است (بهروزرسانی قیمت)، اما اغلب پیچیدهتر:

مشتری باید آگاه شود
باید تصمیم بگیرد
پاسخ از کانالهای مختلف میرسد
و درصورت پذیرش، قرارداد باید بهصورت قانونی آپدیت شود

MaMa-CRM باید بتواند همهٔ این اتفاقات را هماهنگ کند.

۲) پردازش اطلاعات صورتحساب

برای مثال:

شرکتهای «call-by-call» دادههای خام صورتحساب را به MaMa میفرستند.
MaMa:

دادهها را دریافت و پردازش میکند
آنها را برای چاپ و ارسال آماده میکند
و پشتیبانی لازم پس از ارسال را مدیریت میکند

پرداخت و امور مالی خارج از محدودهٔ سیستم هستند.

۳) مدیریت تصاویر کارتها (Credit Card / Insurance / e-Health Card)

بسیاری از کارتها مانند کارت سلامت آلمان، تصویر دارنده را روی کارت چاپ میکنند.
MaMa-CRM باید بتواند:

تصاویر را ذخیره کند
مدیریت چرخه پردازش را انجام دهد
و نتیجه را برای چاپگر کارت آماده کند

۴) مدیریت قرائت کنتور آب/برق/گاز

شرکتهای انرژی یا املاک، دادههای مربوط به قرائت کنتور را جمعآوری و مدیریت میکنند.
MaMa-CRM باید فرآیند جمعآوری داده، هماهنگی، پاسخگویی و پردازش را مدیریت کند.

نکتهٔ کلیدی معماری: انعطافپذیری مطلق در ورودی/خروجی

چون MaMa-CRM نقش یک «پلتفرم CRM چندصنعتی» دارد، یک الزام بزرگ وجود دارد:

MaMa-CRM باید بدون نیاز به تغییر کد، برای هر Mandator و هر کمپین قابل پیکربندی باشد.

این یعنی:

فرمتهای مختلف داده باید پشتیبانی شوند
کانالهای ارتباطی مختلف باید قابل انتخاب باشند
فرآیندها باید قابل تغییر و تنظیم باشند
سیستم باید بتواند با انواع OCR، چاپگر، مرکز تماس، API و غیره صحبت کند

همین الزام پایهٔ بسیاری از تصمیمات معماری MaMa-CRM بوده است.

III.1.1.1 مثال کمپین: اصلاح قرارداد مشترکین یک اپراتور موبایل

برای درک بهتر دامنه و پیچیدگی سیستم، مثال MoPho—a hypothetical mobile provider—در کتاب آورده شده است.

این مثال، ترکیبی از چالشهای تجاری، حجم دیتای بالا و کار عملیاتی است.

MoPho میلیونها مشترک دارد و قصد دارد تعرفههای قدیمی و غیرسودده خود را حذف کند. بنابراین:

تعرفههای جدید را طراحی میکند.
مشتریان واجد شرایط را انتخاب میکند (حدود ۱۰ میلیون نفر).
پیشنهاد جدید را برای آنها ارسال میکند.
به واکنش مشتریان از هر کانال ممکن پاسخ میدهد.
و در صورت پذیرش، قرارداد جدید را ثبت میکند.

MoPho خودش نمیخواهد با پیچیدگیهای عملیاتی درگیر شود:

چاپ نامه
مدیریت بازگشت نامهها
پاسخگویی تلفنی
پردازش فاکس
OCR و پردازش فرمها
تشخیص خطاهای مشتریان
مدیریت استثناها
و صدها حالت مختلف تعامل انسانی

اینها خارج از حوزهٔ تخصص اپراتور هستند.

بنابراین همهٔ این فرایندها را به MaMa-CRM میسپارد.

چرخهٔ کامل این کمپین—گامبهگام

۱) انتخاب و ارسال داده مشتریان به MaMa

MoPho داده ۱۰ میلیون مشتری را استخراج و به MaMa ارسال میکند.
MaMa آنها را وارد سیستم میکند.

۲) ارسال داده لازم برای چاپ نامه

MaMa اطلاعات لازم را به شرکت چاپ (Partner) میفرستد.
این شرکت نامههای شخصیسازی شده را تولید و ارسال میکند.

۳) آمادهسازی مرکز تماس (Partner)

MaMa اطلاعات کمپین را برای Call Center ارسال میکند تا آمادهٔ پاسخگویی باشند.

۴) مدیریت نامههای برگشتی یا ردشده

Postal Service موارد زیر را گزارش میدهد:

آدرس اشتباه
Forwarding request
مشتری نامه را نپذیرفته

MaMa این موارد را تحلیل و تصمیم لازم را میگیرد.

۵) مشتری تصمیم میگیرد

و حالتهای مختلف رخ میدهد:

فرم را کامل میکند و امضا میکند
فرم را پر میکند اما امضا نمیکند
فرم ناقص ارسال میشود
مشتری از طریق تلفن سؤال میکند
مشتری بیتفاوت است
یا شرایط ویژه وجود دارد: زیر سن قانونی، فوت شده، ناتوانی حقوقی و…

۶) فرمها اسکن و OCR میشوند

شرکت Partner فرمها را اسکن و نتیجه را برای MaMa ارسال میکند.

۷) MaMa نتایج را دریافت و تحلیل میکند

۸) تصمیمگیری براساس وضعیت هر مشتری

MaMa باید همهٔ حالات ممکن را مدیریت کند—از کامل بودن تا ناقص بودن یا عدم ارسال.

۹) بهروزرسانی اطلاعات در سیستم Mandator

در نهایت، قراردادهای جدید برای مشتریانی که پذیرش کردهاند ثبت میشود.

مزیت اصلی برای اپراتور چیست؟

MoPho یک چیز بهدست میآورد:

یک نقطهٔ مرکزی برای مدیریت کل کمپین—بدون نیاز به دخالت مستقیم.

و این یعنی:

هزینه کمتر
سرعت بالاتر
کیفیت پاسخگویی بهتر
کاهش خطا
امکان مدیریت میلیونها مشتری

و مخصوصاً:

انعطافپذیری بینهایت در هماهنگسازی با انواع سیستمها و شرکای بیرونی.

1.1.2 Campaign Configuration – پیکربندی کمپینها در MaMa-CRM

MaMa-CRM یک پلتفرم عمومی نیست که بتوان آن را «نصب و اجرا» کرد.
این سیستم یک زیرساخت CRM چندمنظوره است که برای هر Mandator (سازمان مشتری) باید:

پیکربندی شود
شخصیسازی شود
به چندین شریک (Partner) متصل شود
و همهٔ این موارد بدون تغییر کد انجام شوند

بهعبارت دیگر:

هر کمپین در MaMa مانند یک سیستم مستقل است که کاملاً با تنظیمات ساخته میشود.

در ادامه، مراحل اصلی پیکربندی یک کمپین—با مثال MoPho—را مرور میکنیم.

۱) پیکربندی دادههای اصلی مشتری (Client Master Data)

این مرحله معمولاً توسط خود Mandator تأمین میشود و شامل تعریف تمام اطلاعات لازم دربارهٔ:

قرارداد مشتری
تعرفه فعلی
تعرفههای پیشنهادی جدید
تاریخ اعتبار قرارداد فعلی
تاریخ شروع تعرفهٔ جدید

این دادهها در قالب مدلهای UML بهعنوان Extension روی مدل پایهٔ MaMa اعمال میشوند.

به این ترتیب:

مدل پایه ثابت میماند
اما برای هر صنعت (Telecom، Insurance، Banking…) دادههای اختصاصی تعریف میشود

این بخش یکی از مهمترین پایههای انعطافپذیری معماری است.

۲) پیکربندی کانالهای ارتباطی

MaMa-CRM باید با چندین Partner و Mandator ارتباط داشته باشد، بنابراین نیاز است:

تبادل اطلاعات امنیتی مانند رمز عبور، Certificate و User ID
تعریف کانالهای تبادل داده
مشخص کردن نقطه تماس فنی در هر سازمان

این کانالها میتوانند شامل:

اتصال به Print Service Provider
اتصال به Call Center
اتصال به Scan Service Provider
ارتباط با سیستمهای IT خود Mandator

باشند.

۳) تعریف فراداده کمپین (Campaign Meta Data)

برای اینکه یک کمپین CRM بتواند اجرا شود، باید ابتدا:

تاریخ شروع و پایان کمپین
تاریخهای مهم برای فعالیتها
آدرسهای پاسخ (Reply Address)
ایمیل و شمارهٔ اختصاصی Call Center

تعریف شوند.

این اطلاعات برای هماهنگی هزاران یا میلیونها تعامل انسانی ضروری است.

۴) تعریف فعالیتهای کمپین (Campaign Activities)

در MaMa هر کمپین از چندین فعالیت تشکیل شده است که در سه گروه اصلی قرار میگیرند:

الف) فعالیتهای خروجی (Output Activities)

کارهایی که MaMa باید برای ارسال داده انجام دهد، مثلاً:

ارسال داده به شرکت چاپ: PrintLetter
ارسال داده به Call Center
ارسال داده به Scan Service Provider
ارسال نتایج نهایی به Mandator
ارسال سفارش تولید کارت (Card Production Order)

ب) فعالیتهای ورودی (Input Activities)

دادههایی که MaMa باید از Mandator یا Partners دریافت کند:

دادههای اولیه مشتریان (Master Data Import)
دادههای OCR پس از اسکن فرمها
دادههای Call Center
خروجی فروشگاههای حضوری (Sales Outlet Import)

ج) فعالیتهای داخلی (Internal Activities)

کارهای نگهداری و پاکسازی دیتای حساس، مانند:

حذف دادهٔ مشتری ۶۰ روز پس از پایان پردازش
حذف کل دادههای کمپین ۱۲۰ روز پس از پایان رسمی کمپین

(این موارد برای رعایت قوانین امنیت و حریم خصوصی ضروریاند.)

۵) مدلسازی جریان کمپین (Campaign Flow Modeling)

پس از تعریف فعالیتها، باید مشخص شود:

چه فعالیتی در چه شرایطی اجرا میشود؟
مسیرهای خوشرفتار (Happy Path) و مسیرهای خطا چیست؟
اگر داده ناقص باشد چه باید کرد؟
اگر مشتری پاسخ ندهد چه اتفاقی میافتد؟
چگونه plausibility validation انجام میشود؟

این مدل کسبوکار پیچیده، یکی از تفاوتهای اساسی MaMa-CRM با یک CRM معمولی است.

1.1.3 فعالیتهایی که هزینه ایجاد میکنند (Activities Subject to Charge)

در بسیاری از کمپینها، بعضی فعالیتها هزینهٔ مستقیم مالی دارند، مانند:

چاپ و ارسال نامه برای مشتری
تولید کارت برای بیمه یا کارت بانکی (Card Production Charges)

از آنجا که ممکن است میلیونها فعالیت در یک کمپین انجام شود، هزینهها بسیار قابلتوجه هستند.

نکتهٔ مهم:

MaMa-CRM مسئول مدیریت مالی یا تسویه حساب نیست.

صورتحساب و پرداختها توسط واحد مالی InDAC یا خود Mandator مدیریت میشود.
MaMa فقط باید:

تعداد فعالیتها
وضعیت پیگیری
و گزارش دقیق برای حسابداری

را ارائه دهد.

1.1.4 نیازمندیهای تکمیلی

در این بخش چند الزام مهم و غیرقابلچشمپوشی مطرح میشود:

۱) گزارشدهی وضعیت و گزارشهای مالی

MaMa باید گزارشهای جامع ارائه دهد، شامل:

تعداد نامههای ارسالشده
تعداد تماسهای Call Center
تعداد فرمهای بازگشتی
تعداد مشتریانی که تغییر تعرفه را پذیرفتهاند

و بهویژه:

گزارش دقیق فعالیتهای دارای هزینه.

این گزارشها پایهٔ محاسبهٔ هزینهها در InDAC است.

۲) مالکیت داده و الزامات امنیتی

یک اصل بنیادین در MaMa-CRM:

دادهٔ مشتری همیشه متعلق به Mandator است، نه InDAC.

این یعنی:

داده باید محرمانه نگه داشته شود
فقط برای همان کمپین استفاده میشود
پس از پایان رسمی کمپین،
تمام دادهها—شامل Backup، پیکربندی، Metadata—باید حذف شوند

این الزام معماری را بهشدت تحت تأثیر قرار میدهد، مخصوصاً در بخشهای دیتابیس، ذخیرهسازی و جریان داده.

1.2 اهداف کیفی MaMa-CRM – چرا «انعطافپذیری» مهمترین اصل معماری است؟

اگر بخواهیم فقط یک واژه برای توصیف هویت معماری MaMa-CRM انتخاب کنیم، آن واژه Flexibility یا «انعطافپذیری» است.
MaMa-CRM در اصل یک Data Hub بسیار تطبیقپذیر است؛ سیستمی که باید بتواند:

از دهها نوع منبع داده ورودی دریافت کند
قوانین تجاری کاملاً متفاوت را اجرا کند
داده را به انواع شرکای تجاری صادر کند
و این کار را بدون تغییر کد و تنها با «پیکربندی» انجام دهد

این نیازها باعث شده معماری MaMa-CRM حول محور چهار نوع انعطافپذیری طراحی شود:

Aspect 1 — انعطافپذیری در ساختار و فرمت داده

MaMa در تمام کمپینها با دادهٔ مشتری سر و کار دارد؛ اما مشکل اینجاست که:

هر Mandator (بیمه، بانک، تلفن همراه، انرژی…)
هر Partner (چاپ، مرکز تماس، OCR، فروشگاهها)

همه فرمت دادهٔ مخصوص خودشان را دارند.

MaMa باید همهٔ این فرمتها را پشتیبانی کند، از جمله:

فرمتهای متداول

CSV با جداکنندههای مختلف (, ، ; ، | و…)
رشتههایی با کوتیشنهای مختلف (" , ' , « »)
فایلهایی با طول ثابت (Fixed-Length Records)
مجموعهای از XMLهای متفاوت با Schema یا DTDهای سفارشی

اما مهمتر اینکه:

MaMa باید بتواند بدون تغییر کد، فرمت هر Mandator را فقط با پیکربندی قبول کند.

بنابراین سیستم باید:

ترتیب ستونها
انواع دادهها
قواعد اعتبارسنجی (Validation & Plausibility Checks)

را برای هر کمپین بهطور سفارشی پیکربندی کند.

Aspect 2 — انعطافپذیری در روشها و پروتکلهای انتقال داده

MaMa فقط با فرمتها سروکار ندارد—بلکه باید داده را از طریق چندین کانال مختلف دریافت و ارسال کند.

MaMa باید بتواند کار کند با:

ftp و sftp
http و https
(هم به عنوان Client و هم Server)

و همچنین باید بتواند:

دادهٔ فشردهشده را بپذیرد (Compression الگوریتممحور و قابل پیکربندی)
دادهٔ رمزگذاریشده را مدیریت کند (PGP یا مشابه آن)
چکسام تولید کند (MD5، SHA-1 یا شمارندههای مخصوص)
Credentials اختصاصی هر Mandator را مدیریت کند

به زبان ساده:

هر کمپین باید بتواند کانال ارتباطی مخصوص خودش را داشته باشد.

این سطح از انعطافپذیری الزامات امنیتی، کارایی و سازگاری را مستقیماً تحت تأثیر قرار میدهد.

Aspect 3 — انعطافپذیری در قوانین تجاری و قوانین کمپین

اینجا جایی است که MaMa-CRM از یک سیستم ساده به یک «پلتفرم فرآیندی» تبدیل میشود.

برای هر کمپین باید بتوان پیکربندی کرد:

قوانین اساسی کمپین:

کدام فعالیتها باید انجام شوند؟
ترتیب اجرای فعالیتها چیست؟
چه رویدادهایی از طرف Partner باید باعث اجرای کدام فعالیت شوند؟

قوانین تعامل با مشتری:

چند بار باید نامهٔ یادآوری ارسال شود؟
چه زمانی باید مشتری را تلفنی پیگیری کرد؟
کدام اطلاعات از مشتری الزامی است؟
چه زمانی باید دادهها حذف یا آرشیوشده شوند؟

قوانین واکنشی:

اگر مشتری پاسخ نداد چه کنیم؟
اگر فرم ناقص بود چه کنیم؟
اگر امضا نداشت، چطور پیگیری کنیم؟

اینها قوانین ثابتی نیستند؛
هر Mandator قوانین مخصوص خودش را دارد، و MaMa باید همهٔ آنها را بدون تغییر کد پشتیبانی کند.

Aspect 4 — انعطافپذیری در خروجی داده

پس از پردازش دادههای مشتری، MaMa باید نتیجه را به چند Partner مختلف ارسال کند.
هر Partner الزامات خاص خود را دارد:

شرکت چاپ → فرمت Fixed-Length
مرکز تماس → CSV
سیستم کارت سلامت → XML
Mandator → فرمت سفارشی

به همین دلیل، معماری MaMa-CRM باید بتواند:

از یک ورودی مشترک، چندین خروجی متفاوت بسازد—کاملاً با نیاز هر Partner.

یک سناریوی واقعی:

داده از Mandator به صورت CSV وارد MaMa میشود
MaMa آن را پردازش میکند
بخشی از داده باید به Partner A به صورت XML صادر شود
بخش دیگر باید به Partner B در قالب Fixed-Length فرستاده شود

این نیاز، طراحی لایههای Import / Processing / Export را عمیقاً تحت تأثیر قرار میدهد.

1.2.2 Quality Goals (Scenarios) — کیفیتهای سطح ۱

کیفیت شماره یک MaMa-CRM، Flexibility است؛ اما باید بهصورت سناریوی عملی تعریف شود تا معماری سیستم بتواند حول آن طراحی شود.

Prio = 1 (بالاترین اولویت)

سناریوهای کیفیتی شامل این موارد هستند:

۱) MaMa میتواند فرمتهای مختلف داده را Import / Export کند:

CSV قابل پیکربندی
Fixed-Length
XML

۲) MaMa میتواند از چندین پروتکل ارتباطی استفاده کند:

ftp، sftp، http، https
همزمان Client و Server

۳) دادهٔ فشرده و رمزگذاریشده را مدیریت میکند

الگوریتم فشردهسازی قابل تنظیم
PGP یا ابزارهای مشابه برای رمزگذاری
تبادل امن Certificateها پیش از شروع کمپین

۴) مدیریت Metadata مربوط به انتقال

مثلاً:

هش فایل
شمارندهٔ انتقال
ثبت آخرین انتقال موفق

۵) تمام این موارد باید طی یک روز قابل پیکربندی باشند

این نیاز باعث شده بخش "Campaign Configuration" پایهٔ اصلی معماری شود.

1.2.2 اهداف کیفی سطح دوم و سوم

اولویت ۲: امنیت (Security)

در MaMa-CRM، امنیت فقط یک ویژگی فنی نیست؛ هستهٔ وجودی سیستم است.
این پلتفرم حجم عظیمی از دادههای حساس مشتریان را میان Mandatorها، شرکای تجاری، و زیرساخت InDAC جابهجا میکند—و کوچکترین نشت داده میتواند یک بحران حقوقی، مالی و اعتباری ایجاد کند.

بنابراین:

هیچ طرف بیرونی کمپین نباید به دادهها یا فرادادهها دسترسی داشته باشد.
تمام دادهها—اعم از ورودی، خروجی، ذخیرهشده و موقت—باید در کنترل کامل InDAC باقی بماند.
ادمینهای InDAC، قبل از دسترسی به دادهٔ هر کمپین، باید قرارداد عدم افشای اطلاعات امضا کنند (این بخش سازمانی است و جزئیات آن خارج از محدوده سیستم قرار میگیرد).

نتیجهٔ معماری:
معماری MaMa باید امنیت را در تمام لایهها در نظر بگیرد: زیرساخت، الگوهای ارتباطی، رمزگذاری، دسترسیها، تفکیک محیطها، و جداسازی دادههای Mandatorهای مختلف.

اولویت ۳: کارایی اجرایی (Runtime Performance)

MaMa-CRM در برخی کمپینها باید دادههایی در مقیاس کشور پردازش کند. برای مثال:

سیستم باید بتواند ۲۵۰٬۰۰۰ نامه اسکنشده را در کمتر از ۲۴ ساعت پردازش کند.

این الزام باعث میشود:

پردازش داده باید کاملاً بهینه و موازیپذیر باشد
ورودی و خروجی کمپینها باید مقیاسپذیر طراحی شوند
صفها، پردازشهای دستهای و مکانیزمهای Retry بخش جداییناپذیر معماری باشند

این سناریو کیفیت «Performance» را به یک الزام معماری جدی تبدیل میکند.

1.2.3 موارد خارج از محدوده (Non-Goals)

برای جلوگیری از انحراف معماری، MaMa-CRM بهصورت شفاف مشخص کرده چه چیزهایی در حوزهٔ وظایفش نیست:

۱) MaMa یک محصول تجاری عمومی نیست

MaMa قرار نیست تبدیل به نرمافزاری مشابه Salesforce، Siebel یا محصولات CRM بازار شود.
این سیستم صرفاً برای استفادهٔ داخلی InDAC طراحی شده و مستقیماً برای فروش عرضه نخواهد شد.

۲) MaMa جایگزین CRM سازمانی نیست

Mandatorها همچنان CRM اصلی خودشان را دارند؛
MaMa صرفاً یک سیستم عملیات کمپین (Operational Campaign Engine) است—not یک CRM کامل.

۳) MaMa فرایندهای مالی و پرداخت را مدیریت نمیکند

هرچند کمپینها هزینه ایجاد میکنند (مثل چاپ نامه، کارت، تماس تلفنی و…)،

پردازش مالی و پرداختها خارج از محدوده MaMa بوده و توسط بخش مالی InDAC یا خود Mandator انجام میشود.

این تفکیک باعث میشود معماری MaMa سبکتر و متمرکزتر باقی بماند.

1.3 ذینفعان (Stakeholders) — چه کسانی به MaMa شکل میدهند؟

MaMa-CRM یک سیستم چندذینفعی است و معماری آن باید نیازهای گروههای مختلفی را برآورده کند. در ادامه، هر ذینفع را با زبان بلاگی توضیح دادهام.

Mandator — سازمانهایی که کمپینها را سفارش میدهند

اینها شرکتهایی هستند که InDAC را برای اجرای کمپینهای بزرگ انتخاب میکنند: بیمهها، اپراتورها، بانکها، شرکتهای انرژی و…
برای Mandator مهمترین خواستهها عبارتاند از:

وارد کردن دادهٔ اولیه با کمترین تلاش
دریافت خروجیها در قالبهای موردنیاز خود
پیکربندی سریع قوانین کمپین
شفافیت کامل در گزارشدهی فعالیتها

Mandatorها معمولاً دغدغهٔ اجرایی ندارند؛ آنها فقط داده میدهند، نتیجه میخواهند.

مدیریت InDAC — مالک سیستم و مسئول گسترش آن

در سمت InDAC، مدیریت نیاز دارد:

یک پلتفرم انعطافپذیر که بتواند سالها با Mandatorهای جدید سازگار شود
عملکرد بالا و قابلاتکا برای پردازش داده در مقیاس بزرگ
امکانی برای توسعهٔ تدریجی سیستم بر اساس نیازهای جدید

آنها در چرخهای مستمر با تیم معماری و توسعه همکاری میکنند تا نیازهای جدید تعریف شود و سیستم در طول زمان ارتقا پیدا کند.

توسعهدهندگان MaMa-CRM — معماران و سازندگان سیستم

تیم توسعه وظایف زیر را بر عهده دارد:

طراحی ساختار داخلی MaMa
پیادهسازی مؤلفهها و ماژولها
مشارکت فعال در تصمیمات معماری
تضمین پایداری، امنیت و مقیاسپذیری

برای آنها، MaMa یک پلتفرم در حال رشد است، نه یک محصول تمامشده.

شرکای تجاری (Partners) — ارائهدهندگان خدمات جانبی

این گروه شامل:

شرکتهای چاپ
مراکز تماس
سرویسهای اسکن و OCR
ارائهدهندگان کارت هوشمند
شرکتهای پستی و لجستیک

نیاز اصلی آنها:

دریافت داده از MaMa در قالبی دقیق و سازگار
ارسال دادهٔ پردازششده به MaMa با فرمت توافقشده
داشتن رابطهای ارتباطی پایدار و امن

تعامل مؤثر MaMa با این شرکا، موفقیت کمپین را تضمین میکند.

نهادهای دولتی و قانونگذار

در بسیاری از کشورها کمپینهایی مثل تغییر قرارداد بیمه یا کارت سلامت تحت مقررات سختگیرانه هستند.
نهادهای دولتی وظیفه دارند اطمینان حاصل کنند:

دادهٔ مشتریان بهدرستی محافظت میشود
فرآیندها با قوانین IT-security و حفاظت داده سازگار هستند
محرمانگی و نگهداری داده با استانداردهای قانونی همخوان است

این نقش مستقیماً روی سیاستهای امنیتی MaMa تأثیر میگذارد.

جامعه Eclipse RCP (پلتفرم UI)

MaMa برای UI خود از Eclipse RCP استفاده میکند.
چالش اصلی اینجاست که Eclipse API را مرتب تغییر میدهد و این موضوع روی توسعهٔ رابط کاربری MaMa اثرگذار است.

بنابراین تیم MaMa باید دائماً تغییرات پلتفرم را رصد و با نسخههای جدید هماهنگ شود.

۱.۳.۱ مورد ویژه: پروژهٔ کارت سلامت الکترونیک آلمان (German e-Health Card)

یکی از پیچیدهترین کمپینهایی که InDAC با استفاده از MaMa-CRM میزبانی کرد، پروژهٔ آزمایشی کارت سلامت الکترونیک آلمان بود.

این پروژه تحت نظارت یک نهاد دولتی تازهتأسیس انجام میشد؛ نهادی که مسئول تعریف استانداردهای فنی و امنیتی کارت سلامت بود.

نکتهٔ چالشبرانگیز برای تیم MaMa-CRM:

در آغاز توسعه، استانداردهای رسمی هنوز وجود نداشتند.

یعنی تیم باید سیستمی طراحی میکرد که:

با استانداردهایی غیرقطعی و در حال تدوین سازگار شود
سطح امنیت بسیار بالا داشته باشد
بتواند در آینده با الزامات رسمی منطبق گردد
و هنوز انعطافپذیری گسترده MaMa را حفظ کند

این سناریو یکی از نقاطی بود که «اهمیت انعطافپذیری» در معماری MaMa را بهشدت برجسته کرد.

۱.۳.۲ نقش Mandator و Partner در تعیین جزییات ارتباطی

MaMa-CRM مجموعهای از اسناد استاندارد مشخصات اتصال ارائه میدهد؛ اسنادی که باید توسط شرکای کمپین (مثل چاپ، اسکن، مرکز تماس، شرکت پستی و…) برای اتصال به MaMa استفاده شوند.

اما در عمل همیشه اینگونه پیش نمیرود.

به دلیل انعطاف زیاد MaMa، معمولاً اتفاق برعکس میافتد:

Mandatorها و Partnerها فرمت داده و قرارداد ارتباطی خودشان را ارائه میکنند،
و MaMa فقط آنها را پیکربندی میکند—بدون تغییر کد.

این ویژگی برای InDAC یک مزیت رقابتی عظیم است:
اضافهکردن یک Partner یا شروع یک کمپین جدید فقط به تنظیمات وابسته است، نه توسعهٔ نرمافزار.

III.2 محدودیتها و الزاماتی که معماری MaMa را شکل دادهاند

در طراحی یک پلتفرم CRM در مقیاس ملی، محدودیتها نقشی تعیینکننده دارند.
در MaMa، این Constraints جزو ستونهای اصلی معماری هستند.

۱) محدودیتهای کلی معماری

بدون برنامهنویسی، فقط با پیکربندی باید بتوان کمپین ساخت

این مهمترین اصل معماری است:
برای ساخت یا اجرای یک کمپین جدید، هیچ تغییری در کد نباید لازم باشد.
هرچیز باید از طریق پیکربندی (فایل، UI یا ابزار اختصاصی) انجام شود.

تکنولوژی پایه: Java

MaMa باید روی نسخههای جدید JVM قابل اجرا باشد (حداقل نسخه ۱.۶).
تمام قابلیتها و توسعهها بر این اساس طراحی شدهاند.

بانک اطلاعاتی اجباری: Oracle

این محدودیت به انتخاب تیم نبود؛
Holding شرکت InDAC قرارداد سازمانی با Oracle داشت،
بنابراین MaMa-CRM اجباری بود روی Oracle پیادهسازی شود.

۲) محدودیتهای زیرساخت نرمافزار

سیستمعامل: Linux (ترجیحاً RedHat Enterprise)

به دلیل سختگیریهای امنیتی، نسخههای Hardened ردهت انتخاب اصلی بودند.

استفاده از نرمافزارهای متنباز با لایسنس آزاد

GNU و FSF مجاز نبودند
—در نتیجه انتخاب ابزارها کاملاً محدود میشد.

ترجیح توسعه مبتنی بر Code Generation / مدلسازی MDSD

توسعه باید با حداقل کدنویسی و حداکثر تولید خودکار انجام شود.
این موضوع بر ساختار لایه دامنه و مدل داده اثر جدی گذاشت.

استفاده از ابزار مدلسازی (UML) توصیهشده

به دلیل نیاز به مستندسازی سنگین، UML یکی از ابزارهای کلیدی تیم بود.

توسعهٔ تدریجی (Iterative) توصیه میشود

اما اجباری نبود؛ تیم آزادی عمل داشت تا روش مناسب خود را انتخاب کند.

نیاز به مستندسازی فنی «عمیق و پایدار»

InDAC تأکید داشت که:

سیستم باید قابل نگهداری در درازمدت باشد
مستندات باید واضح، بهروز، و دقیق باشند

به همین دلیل arc42 اساس کار قرار گرفت.

۳) محدودیتهای عملیاتی (Operational Constraints)

هر کمپین باید روی یک VM جداگانه اجرا شود

این الزام امنیتی باعث شد MaMa یک سیستم کاملاً Multi-Instance باشد.
هیچ کمپینی نباید داده یا فرآیند کمپین دیگر را ببیند.

اجرا به صورت Batch / Background

بیشتر پردازشها:

زمانبر،
دادهمحور،
و شدیداً وابسته به شرکا هستند.

بنابراین MaMa باید بدون رابط تعاملی،
و صرفاً در حالت پردازش پسزمینه اجرا شود.

تمام پیکربندیها باید از طریق یک افزونهٔ سفارشی Eclipse یا رابط وب قابل انجام باشد

تیم InDAC به ابزاری نیاز داشت که بتواند:

کمپین را ایجاد کند
ورودی/خروجیها را تنظیم کند
قوانین را تعریف کند
و تمام چیزها را بدون لمس Backend پیکربندی کند

این مورد تأثیر مستقیم روی طراحی UI و API داخلی MaMa داشت.

III.3 محدودهٔ سیستم و تعاملات آن System Scope and Context

MaMa-CRM یک سیستم کاملاً «بین سازمانی» است.
هر نمونه از MaMa برای یک Mandator و چندین Partner کار میکند.
این یعنی هر instance دارای مجموعهای کاملاً مستقل از ورودیها، خروجیها، قوانین و تبادلات داده است.

۳.۱ زمینه کسبوکار (Business Context)

MaMa میان سه گروه داده جریان ایجاد میکند:

۱) Mandator ↔ MaMa

Mandator دادههای اولیه کمپین را ارائه میکند، شامل:

دادهٔ مشتری
قراردادها
تعرفهها
قوانین کمپین

MaMa این داده را پردازش میکند و در پایان، نتیجه نهایی کمپین را به Mandator بازمیگرداند.

تبادلات دادهٔ کلیدی شامل:

Master Data (ورودی)
وضعیت کمپین (خروجی دورهای)
درخواستهای رفع ابهام
(مثلاً وقتی آدرس غلط است، امضا ناقص است یا دادهٔ مشتری معتبر نیست)

این دادهها کاملاً حساس هستند و باید طبق قانون حفاظت داده نگهداری شوند.

۲) Partner ↔ MaMa

Partnerها شامل:

چاپ
اسکن
OCR
پست
مرکز تماس
فروشگاهها
ارائهدهندگان کارت سلامت

هستند.

دادههای رد و بدلشده:

ارسال دادهٔ مشتری به Partner (Outbound)
دریافت نتایج اولیه از Partner (Inbound)
این دادهها شامل:
- اسکنها
- نتیجهٔ تماسها
- وضعیت تحویل نامه
- لاگهای پردازش

MaMa باید قبل از استفاده، نتایج را تحلیل و به وضعیت نهایی تبدیل کند.

۳) اصل "Data Minimization"

نکتهٔ بسیار مهم در معماری:

هر Partner فقط دادهای را دریافت میکند که واقعاً نیاز دارد.

مثلاً:

مرکز تماس → فقط نام و شماره تماس
سرویس چاپ → فقط آدرس و دادههای مربوط به نامه
شرکت کارت → فقط تصویر و مشخصات لازم برای چاپ کارت

این اصل، هم امنیت را افزایش میدهد، هم ریسکهای قانونی را کاهش میدهد.

۳.۱ زمینهٔ کسبوکار (نسخهٔ رسمی) – Formal Business Context

در نسخهٔ رسمیتر از دیاگرام زمینهٔ کسبوکار MaMa-CRM، یک بخش مهم اضافه میشود: رابط مدیریت (Admin Interface).

این رابط برای تیمهای MaMa و مدیران کمپینها ضروری است، زیرا تمام عملیات حیاتی سیستم از طریق آن انجام میشود:

ایجاد یک کمپین جدید
پیکربندی قوانین، فعالیتها و جریان کار
تعریف ورودی و خروجیهای داده
مدیریت کاربران و سطح دسترسیها
نظارت بر وضعیت کمپین و کنترل عملیات

در واقع، Admin Interface مغز کنترل MaMa است؛ بخشی که اجازه میدهد بدون تغییر کد، دهها کمپین مختلف برای دهها Mandator اجرا شود.

در این دیاگرام رسمی (که در کتاب arc42 نمایش داده شده)، MaMa در مرکز قرار میگیرد و بهعنوان سیستم هماهنگکنندهٔ اصلی بین Mandator، Partnerها و مدیران سیستم عمل میکند.

۳.۱.۲ زمینهٔ کسبوکار اختصاصی – سناریوی «اصلاح قرارداد موبایل»

در بخش 1.1.1 یک نسخهٔ مفهومی از این سناریو ارائه شد. اما در اینجا ساختار دقیقتر و رسمیتری از تعامل سیستمها و جریان داده نمایش داده میشود.

این سناریو یکی از پیچیدهترین نمونههای کمپین است، زیرا:

چندین منبع داده
چند مقصد خروجی
تبادلات چندمرحلهای
فرآیندهای انسانی و ماشینی
و قواعد پیچیده تجاری

را درگیر میکند.

تصویر کلی سناریو:

Mandator (اپراتور موبایل) دادهٔ مشتریان را بارگذاری میکند →
MaMa داده را پردازش میکند →
اطلاعات لازم به Partnerهای مختلف ارسال میشود (چاپ، اسکن، مرکز تماس…) →
نتایج آنها به MaMa بازمیگردد →
MaMa همه چیز را تفسیر کرده و نتیجهٔ نهایی را به Mandator برمیگرداند.

جریانهای داده در سناریوی اصلاح قرارداد موبایل

۱) دادهٔ ورودی از Mandator → به MaMa (Inbound)

Mandator مجموعهای از اطلاعات پایه مشتری را ارسال میکند:

نام، آدرس و اطلاعات تماس
اطلاعات قرارداد فعلی
جزئیات تعرفهٔ فعلی و تاریخ اعتبار
شناسهٔ مشتری و شمارهٔ قرارداد

این دادهها معمولاً:

در قالب CSV
Zip شده
و از طریق sftp

بارگذاری میشوند.

این انتقال دو بار انجام میشود:

بار اول: هنگام شروع کمپین
بار دوم: هنگام پاسخ به Clarification Requestهای MaMa

۲) خروجی MaMa → به Mandator (Outbound)

زمانی که MaMa تمام دادهها را پردازش کرد، نتیجهٔ نهایی را ارسال میکند:

کدام مشتریان پیشنهاد جدید را پذیرفتهاند
تغییرات لازم در قرارداد
تعرفهٔ جدید و تاریخ اعمال آن

این خروجی نیز Zip و از طریق sftp ارسال میشود.

MaMa همچنین درخواستهای رفع ابهام را نیز از همین مسیر ارسال میکند:

دادهٔ ناقص
آدرس اشتباه
نبودن امضا
دادهٔ متناقض با قوانین کمپین

۳) دادهٔ خروجی MaMa → به Print Provider

MaMa باید بخشهای مرتبط از داده را به سرویس چاپ ارسال کند:

نام
آدرس
بخشهایی از اطلاعات قرارداد یا تعرفه

برای امنیت بیشتر:

فایل CSV فشرده میشود (Zip)
سپس PGP رمزگذاری میشود
و از طریق HTTP Upload امن منتقل میشود

نگاشت فیلدها و قالب داده

هر Mandator و Partner فرمت مخصوص خود را دارد.
بنابراین لازم است:

برای هر Instance از MaMa، نگاشت دقیق فیلدهای داده به ستونهای CSV یا رکوردهای ثابت تعریف شود.

این کار با استفاده از یک DSL اختصاصی انجام میشود
(توضیح کامل این DSL در بخش ۸.۳ کتاب آمده است: CSV-Import/Export).

این DSL به MaMa اجازه میدهد:

بدون تغییر حتی یک خط کد
ساختار دادهٔ هر Mandator را تعریف و اعمال کند
و ورودی و خروجیهای متعدد را مدیریت کند

این بخش یکی از دلایل کلیدی معماری «پلتفرم چندسازمانی» بودن MaMa است.

۳.۱.۲ زمینهٔ کسبوکار اختصاصی: سناریوی «اصلاح قرارداد موبایل»

این بخش نسخهٔ رسمیتر و فنیتر همان مثال فصل 1.1.1 است: کمپین تغییر تعرفهٔ یک اپراتور موبایل (MoPho).
در این سناریو، MaMa-CRM نقش «ستون فقرات داده و فرآیند» را ایفا میکند و ارتباط میان Mandator، شرکای بیرونی، و مشتریان را هماهنگ میسازد.

این سناریو دقیقاً نشان میدهد که چرا MaMa باید اینقدر انعطافپذیر، مقیاسپذیر و ایمن باشد.

جریانهای داده در کمپین تغییر قرارداد موبایل

۱) دادهٔ ورودی از Mandator → به MaMa

Mandator (اپراتور موبایل) برای شروع کمپین، اطلاعات کامل مشتریان را در اختیار MaMa قرار میدهد. این داده شامل:

نام و نام خانوادگی
آدرس کامل
اطلاعات تماس
اطلاعات قرارداد فعلی
تعرفهٔ فعلی و تاریخهای اعتبار
کد مشتری یا شناسهٔ مشترک

این دادهها در دو موقعیت ارسال میشوند:

در آغاز کمپین
هنگام پاسخ به Clarification Requestها

قالب انتقال

فایل CSV
فشردهشده با Zip
منتقلشده از طریق sftp
آپلود توسط خود Mandator

۲) خروجی MaMa → به Mandator

پس از پردازش کامل دادهها و دریافت اطلاعات از Partnerها، MaMa نتیجهٔ نهایی را برای Mandator ارسال میکند.
این نتایج شامل:

وضعیت نهایی هر مشتری
تعرفهٔ جدید انتخابشده
تغییرات لازم در قرارداد
تاریخ اعمال تغییر

خروجی نیز مانند ورودی:

CSV
Zip شده
از طریق sftp ارسال میشود

MaMa همچنین درخواستهای رفع ابهام (Clarification Requests) را نیز از همین مسیر ارسال میکند.

۳) خروجی MaMa → به سرویس چاپ (Print Service Provider)

برای ارسال نامههای پیشنهاد به مشتریان، MaMa بخشهای مرتبط از دادهها را به شرکت چاپ ارسال میکند:

نام مشتری
آدرس پستی
بخشهای موردنیاز از اطلاعات قرارداد و تعرفه

اما این انتقال از حساسترین بخشهای کمپین است.

به همین دلیل:

دادهها ابتدا Zip میشوند
سپس با PGP رمزگذاری میشوند
و نهایتاً از طریق HTTP Upload امن ارسال میگردند

اینجا امنیت، محرمانگی و یکپارچگی داده نقش حیاتی دارند.

نگاشت فیلدها: هر Mandator، زبانی متفاوت برای داده دارد

یکی از چالشهای اصلی MaMa این است که:

هر Mandator و هر Partner قالب داده مخصوص خودش را دارد.

برای همین، MaMa یک زبان DSL اختصاصی ارائه کرده است که با آن میتوان:

فیلدهای مشتری
ستونهای CSV
فرمت رکوردها
قواعد پردازش و اعتبارسنجی

را برای هر کمپین، بدون تغییر در کد، فقط از طریق پیکربندی تعریف کرد.

این DSL ستون اصلی Data Flexibility در معماری MaMa است.
توضیح فنی این DSL در بخش ۸.۳ کتاب آمده.

۳.۲ زمینهٔ فنی و استقرار (Technical / Deployment Context)

MaMa-CRM یک سیستم کاملاً multi-instance است؛ یعنی:

برای هر Mandator، یک MaMa مستقل اجرا میشود
هر کمپین، محیط مخصوص خود را دارد
هیچ دادهای نباید میان کمپینهای مختلف قابل مشاهده باشد

به همین دلیل معماری MaMa از پایه چند-نمونهای طراحی شده است.

استقرار MaMa چگونه انجام میشود؟

۱) هر MaMa instance روی یک ماشین مجازی جداگانه اجرا میشود

در حالت استاندارد:

هر کمپین یک VM لینوکسی مستقل دارد
بانک اطلاعاتی آن نیز روی همان VM قرار دارد
ارتباطات خارجی فقط از مسیرهای کنترلشده مجاز است
دسترسی ssh تنها برای شبکه داخلی InDAC فعال است

اما برخی Mandatorهایی که سطح امنیت بسیار بالایی میخواستند، اصرار داشتند:

MaMa برای کمپین آنها باید روی یک سرور فیزیکی اختصاصی نصب شود.

این موضوع به طور طبیعی هزینهٔ کمپین را افزایش میدهد.

۲) سختافزار InDAC

تمام instanceها روی سرورهای سازمانی مستقر هستند:

Dell، HP یا سختافزار مشابه
سیستمعامل RHEL
مجهز به زیرساخت مجازیسازی (Hypervisor)

۳) Mandator و Partner

برای هر MaMa:

یک Mandator وجود دارد (اپراتور موبایل، بیمه، بانک، انرژی و…)
چندین Partner وجود دارد (چاپ، اسکن، مرکز تماس، پست، OCR و…)

هر Partner یک کانال ارتباطی اختصاصی با MaMa دارد.
این کانال میتواند:

sftp
ftp
http(s)
و حتی پروتکلهای سفارشی

باشد.

۴) بانک اطلاعاتی مستقل

هر MaMa instance بانک اطلاعاتی Oracle خودش را دارد.
چرا؟

جداسازی امنیتی
استقلال عملیاتی
امکان پاکسازی کامل دادهها پس از پایان کمپین
پرهیز از درهمتنیدگی ساختار داده Mandatorهای مختلف

III.4 استراتژی راهحل (Solution Strategy)

«چطور معماری MaMa کیفیتهای موردنیاز را تأمین میکند؟»

در این بخش، MaMa-CRM توضیح میدهد که برای رسیدن به مهمترین نیازهای کیفی—بهخصوص Flexibility و Performance—از چه رویکردهای معماری استفاده شده است.
این بخش عصارهای از تصمیمات کلیدی است؛ تصمیماتی که پایهٔ کل معماری MaMa را شکل میدهند.

۱) انعطافپذیری در ساختار داده (Flexible Data Structure)

یکی از چالشهای اصلی MaMa این است که هر Mandator ساختار دادهٔ مشتریان خود را دارد.
راهحل معماری:

ساختار پایگاه داده و کد persistence بهطور ۱۰۰٪ از مدل UML تولید میشود.

یعنی:

برای هر کمپین، یک مدل دامنه تعریف میشود
کد و جدولهای پایگاه داده از آن مدل تولید میشوند
بدون نیاز به دستکاری دستی، کد همیشه مطابق مدل بهروز است

این باعث میشود MaMa بتواند برای هر Mandator و هر کمپین، ساختاری متفاوت داشته باشد—بدون تغییر در منطق اصلی سیستم.

۲) انعطافپذیری در فرمتهای ورودی/خروجی (CSV & Fixed-Length Files)

MaMa باید داده را در فرمتهای مختلفی دریافت و ارسال کند.
راهحل:

یک زبان دامنهمحور (DSL) اختصاصی برای تعریف CSV و Fixed-Length ایجاد شده است.

این DSL:

ساختار هر فایل
ترتیب فیلدها
قواعد اعتبارسنجی
نحوهٔ تفسیر داده

را بهصورت پیکربندی تعریف میکند.

برای این DSL، تیم MaMa:

یک Parser مبتنی بر ANTLR ساخته
و Interpreterهای لازم را پیادهسازی کرده

این باعث شده اضافهکردن یک Partner جدید فقط به معنی ایجاد یک فایل DSL جدید باشد نه نوشتن کد جدید.

۳) ایجاد Editor اختصاصی برای DSL (Eclipse Plugin)

برای اینکه مدیران کمپین بتوانند بدون دانش فنی ساختار داده را تعریف کنند، MaMa یک ویرایشگر اختصاصی داخل Eclipse RCP ساخته است.

این ویرایشگر:

خطاها را در لحظه بررسی میکند
ساختار فایل و انواع داده را پیشنهاد میدهد
امکان تولید خودکار mapping را فراهم میکند

این ابزار عملاً DSL را از یک ابزار توسعهای به یک قابلیت عملیاتی تبدیل کرده است.

۴) کارایی بالا برای پردازش تصویر (Performance Strategy)

در کمپینهایی مثل کارت سلامت، MaMa باید صدها هزار تصویر را پردازش کند.
راهحل:

تصاویر در پایگاه داده ذخیره نمیشوند
بلکه روی فایلسیستم ذخیره میشوند
برای هر تصویر از Client-ID یک مسیر و نام یکتای قابل پیشبینی ساخته میشود
تست بار (Load Testing) بخشی از CI شده
ابزار تولید دادهٔ تست برای عملکرد ایجاد شده

این تصمیم باعث شده MaMa بتواند:

۲۵۰٬۰۰۰ تصویر را در کمتر از ۲۴ ساعت پردازش کند.

III.5 نمای بلوکهای سازنده (Building Block View)

«معماری MaMa از چه بخشهایی تشکیل شده و هر بخش چه نقشی دارد؟»

نمای Building Block لایههای اصلی سیستم را توضیح میدهد.
در سطح ۱ (Whitebox Level 1)، ما ساختار کلی MaMa را میبینیم—تقسیمشده بر اساس مسئولیتهای عملکردی.

۵.۱ سطح سفید MaMa (Whitebox Level 1)

معماری MaMa بر پایهٔ دو اصل ساخته شده است:

Functional Decomposition → تقسیم سیستم به بخشهایی با مسئولیت مشخص
Generated Persistence → تولید کامل بخش داده بر اساس UML

در این سطح، MaMa از چند بلوک اصلی تشکیل شده است:

۱) Import Handler — ورودیگیر انعطافپذیر

این ماژول وظیفه دارد:

داده را از Mandator یا Partner دریافت کند
فرمتهایی مثل CSV، Fixed-Length و XML را پردازش کند
دادهٔ فشرده یا رمزگذاریشده را مدیریت کند
خطاهای ارتباطی یا ساختاری را مدیریت کند

ویژگی کلیدی:
پشتیبانی از کانالهای ورودی کاملاً پیکربندیپذیر.

۲) Export Handler — ارسالکنندهٔ داده به شرکا

کارها شامل:

ارسال دادهٔ پردازششده به چاپ، اسکن، مرکز تماس یا Mandator
اعمال فیلترها و تبدیلها
مدیریت رمزگذاری، فشردهسازی و اعتبارسنجی

این Handler مکمل Import Handler است و مشابه آن بر پایهٔ DSL عمل میکند.

۳) Configuration — قلب پیکربندی کمپینها

این بخش مسئول تمام پیکربندیهای حیاتی است:

قالب ورودی/خروجی
کانالهای ارتباطی
اطلاعات امنیتی
قوانین کمپین (Campaign Rules)
فعالیتها، فلوها و شرطها
نگهداری و آرشیو داده

تنها با تغییر این بخش، میتوان یک کمپین کاملاً جدید ایجاد کرد.

۴) Reporting — گزارشدهی وضعیت کمپین

وظایف:

تولید گزارشهای وضعیت برای Mandator و Partnerها
نمایش پیشرفت کمپین
ارائهٔ گزارش فعالیتهای حساس مالی

۵) Process Control — موتور اجرای کمپین

مهمترین بخش MaMa:

اجرای قوانین کمپین
ترتیب فعالیتها
مدیریت Workflow
زمانبندی عملیات
اجرای Import/Export بر اساس رویدادها

Process Control چیزی شبیه «موتور جریان کار» (Workflow Engine) است.

۶) Campaign Data Management — لایهٔ دادهٔ تولید شده

کاملًا:

از روی UML تولید میشود
مستقل برای هر کمپین
شامل ساختار مشتری، قرارداد، فعالیتها و وضعیتها

۷) Operations Monitoring — نظارت عملیاتی

وظایف:

مانیتورینگ Import و Export
نظارت بر دیتابیس
مشاهدهٔ وضعیت کمپین
مدیریت هشدارها

این ابزارهای نظارت برای مدیریت چندین کمپین همزمان حیاتی هستند.

۸) Code Generator — قلب توسعهٔ سریع

این بخش بهصورت خودکار:

ساختار DB
کد persistence
entityها

را بر اساس مدل UML ایجاد میکند.

این قابلیت یکی از نقاط قوت اساسی MaMa است.

Import Handler — قلب ورودی داده در MaMa-CRM

Import Handler یکی از حیاتیترین اجزای MaMa است؛ زیرا دقیقاً همان نقطهای است که دادهها از Mandatorها و Partnerها وارد سیستم میشوند.
در کمپینهایی که میلیونها مشتری یا صدها هزار فایل اسکنشده وارد سیستم میشود، نحوهٔ مدیریت دادهٔ ورودی نقش تعیینکنندهای در کارایی و صحت کل کمپین دارد.

Import Handler مسئول انجام سه کار کلیدی است:

دریافت داده از طریق کانالهای مختلف
اعمال پردازشهای لازم براساس فرمتها، فیلترها و رمزگذاریها
تبدیل دادهٔ خام به مدل دامنهٔ MaMa و ذخیرهٔ آن

به صورت خلاصه:

Import Handler پلی میان دنیای نامنظم شرکای بیرونی و مدل دادهٔ دقیق MaMa است.

مسئولیتها و قصد طراحی

Import Handler میتواند:

CSV،
فایلهای Fixed-Length،
یا XML

را با ساختارهای قابل پیکربندی دریافت و پردازش کند.
حتی اگر داده:

فشرده شده،
رمزگذاری شده،
یا ترکیبی از این دو باشد،

Import Handler آن را مدیریت میکند.

این قابلیت به دلیل نیاز کمپینها به فرمتهای متنوع اطلاعات واقعاً حیاتی است.

چگونه کار میکند؟ (Interfaces)

شرح بلاگی از رفتار Import Handler:

۱) خواندن تنظیمات Import

پیش از هر چیز، Import Handler تنظیمات مخصوص کمپین را میخواند:

ساختار CSV
قوانین فیلتر (decrypt, unzip…)
کانال انتقال (ftp، http، sftp)
اطلاعات امنیتی

اینکار باعث میشود Import Handler در هر کمپین رفتار متفاوتی داشته باشد—بدون هیچ تغییر در کد.

۲) دریافت فایل یا داده از Mandator/Partner

Import Handler مستقیماً با محیط بیرونی تعامل دارد:

اتصال به ftp یا sftp
خواندن فایل از سیستم فایل
دریافت داده از یک سرویس http

این نقطهٔ تماس معماری با محیط خارج از سیستم است.

۳) تبدیل داده به Client و ذخیره کردن

پس از پردازش:

دادههای خام تبدیل به آبجکتهای دامنه (Client, Contract…) میشوند
سیستم با CampaginDataManagement تماس میگیرد تا این اطلاعات درج یا بهروزرسانی شود

این نقطهٔ اتصال ورودی به مدل دادهٔ داخلی MaMa است.

مدیریت خطا: نقطهٔ قوت Import Handler

Import Handler مجموعهٔ قدرتمندی از مکانیسمهای مدیریت خطا دارد:

خطاهای ارتباطی (شبکه، دسترسی، ftp…)
خطاهای ساختار داده
خطاهای مربوط به فشردهسازی
خطاهای رمزگشایی
خطاهای رکوردهای ناسالم

تقریباً همهٔ خطاهای سطح رکورد قابل بازیابیاند و فقط لاگ میشوند.
فقط خطاهای بحرانی باعث توقف فرآیند میشوند.

این طراحی به MaMa امکان میدهد با کیفیت دادهٔ بسیار متفاوت شرکا کنار بیاید.

Configuration — موتور انعطافپذیری MaMa

اگر Import Handler «دهان سیستم» باشد، Configuration مغز سیستم است.
همهچیز در MaMa باید بدون برنامهنویسی قابل تغییر باشد؛ از جمله:

قالبهای ورودی و خروجی
مسیرها و پروتکلهای ارتباطی
قوانین کمپین
فعالیتها و ترتیب آنها
نحوهٔ رمزگذاری/فشردهسازی دادهها

Configuration دقیقاً این کار را انجام میدهد.

چه چیزهایی با Configuration کنترل میشود؟

۱) تنظیمات Import/Export

شامل:

CSVهای قابلپیکربندی
fixed-length formats
XML-custom
endpointهای شبکه
نوع رمزگذاری و فشردهسازی
اطلاعات امنیتی برای اتصال به شرکا

۲) تنظیمات کمپین

در هر کمپین نیاز است تعریف شود:

چه فعالیتهایی وجود دارد؟ (Import, Export, Maintenance…)
چه دادههایی الزامی هستند؟
چه رویدادهایی باعث اجرای چه فعالیتی میشوند؟
دادهها چه زمانی پاک/آرشیو میشوند؟

این بخش یکی از حساسترین قسمتهای MaMa است.

۳) قوانین نگهداری و آرشیو

مثلاً:

حذف داده ۶۰ روز پس از پایان پردازش
حذف کل دادهٔ کمپین ۱۲۰ روز پس از پایان رسمی کمپین

نحوهٔ تعامل

تمام فراخوانیهای Configuration باید با:

campaignID
mandatorID

انجام شوند، زیرا هر کمپین کاملاً مستقل است.

چیزی که مهم است:

هیچ بخشی از سیستم بهطور مستقیم ساختار فایلها را نمیداند؛ همهچیز از Configuration میآید.

این معماری باعث ایجاد استقلال شدید، و انعطافپذیری حداکثری میشود.

MaMa Level 2 — ساختار Whitebox Import Handler

برای مدیریت جریان ورودی داده، Import Handler به بخشهای داخلی مختلفی تقسیم شده است. این یک معماری pipeline-محور است:

دریافت فایل
فیلترها (decrypt/unzip)
تقسیم رکوردها
اعتبارسنجی
تبدیل به آبجکت
ذخیرهسازی

اجزای زیر این مراحل را انجام میدهند:

Receiver — نقطهٔ ورود داده

وظیفهٔ Receiver:

گوش دادن به پوشهها (Directory Listener)
یا سرویسهای وب
یا Listenerهای پیام

Receiver اولین نقطهای است که داده وارد سیستم میشود.

ImportErrorHandler — خطامدیری قدرتمند

این بخش:

هر نوع خطا را شناسایی میکند
خطاهای جدی را متوقف میکند
خطاهای سطح رکورد را ثبت میکند
برای خطاهای قابلبازیابی، پردازش را ادامه میدهد

این توانایی برای کار با دادههای ناسازگار از چندین Partner ضروری است.

ImportData Port — اتصال به بیرون

این مؤلفه مستقیماً با سیستمهای خارجی صحبت میکند:

ftp
http
VPN

این دقیقاً "دروازهٔ ارتباطی MaMa" است.

FileArchiver — آرشیو غیرقابل حذف

تمام فایلهای ورودی باید برای ممیزی ذخیره شوند.
این آرشیو:

غیرقابل حذف
قابل بازرسی
و مستقل از فرایند Import

است.

FileFilter — لایهٔ فیلترهای پردازش

شامل:

decrypt
unzip
decompression
و هر فیلتر دیگری که در DSL تعریف شود

این همانجاست که قالب فایل به حالت استاندارد تبدیل میشود.

Validator — اعتبارسنج داده

از سطح فایل تا سطح رکورد، Validator بررسی میکند:

فرمت داده درست باشد
مقادیر با قوانین کمپین سازگار باشند
اشیاء ساختهشده معتبر باشند

UnMarshaller — تبدیل رشته به آبجکت

یکی از بخشهای جادویی MaMa.
با استفاده از Reflection:

خطوط و رکوردهای فایل تبدیل به آبجکتهای دامنه (Client, Contract…) میشوند.

این بخش پیچیده است، اما ستون اصلی سیستم هنگام ورود داده است.

MaMa Level 3 — جزئیات داخلی Receiver

Receiver خود به چند بخش تقسیم میشود:

لایهی Directory/WebService/Message Listener

این لایه:

ورود فایلها را زیر نظر دارد
پوشههای محلی یا ریموت را مانیتور میکند
پیامها یا سرویسهای وب را گوش میدهد

Receiver بسته به کمپین، متفاوت پیکربندی میشود.

FileProcessor — قلب جریان ورودی

این بخش:

فایل را unzip میکند
decrypt میکند
آن را آرشیو میکند
رکوردها را جدا میکند
و همهٔ فیلترها را اعمال میکند

در کتاب اشاره شده:

«کد آن شبیه اسپاگتی است!»
اما در عمل، این بخش حجم اصلی پردازش خام ورودی را انجام میدهد.

مولفه FileToRecordSplitter

این مؤلفه:

فایل را به رکوردهای منطقی تبدیل میکند
معمولاً هر خط = یک رکورد است
اما در برخی فرمتها چند خط یک رکورد را تشکیل میدهند

این بخش کاری شبیه parsing اولیه انجام میدهد.

III.6 نمای زمان اجرا (Runtime View)

«MaMa در عمل چگونه کار میکند؟»

تا اینجا معماری MaMa-CRM را بهصورت ایستا دیدیم: کامپوننتها، مسئولیتها و ساختار کلی.
اما Runtime View نشان میدهد که این اجزا در زمان اجرا چگونه با هم تعامل میکنند و یک سناریوی واقعی را به پایان میرسانند.

یکی از مهمترین و پرتکرارترین سناریوها در MaMa، وارد کردن فایل (Import File) است.

6.1 سناریوی Import File

فایلهای ورودی میتوانند از طرف Mandator یا Partner ارسال شوند، اما یک ویژگی مشترک دارند:

همهٔ آنها حاوی دادههای مرتبط با Client هستند
و در قالبهایی مانند CSV، Fixed-Length یا XML میآیند.

معماری MaMa این سناریو را عمداً به دو فاز جدا تقسیم کرده است:

Import Raw File (دریافت و آمادهسازی فایل خام)
Validate & Process (اعتبارسنجی و بهروزرسانی دیتابیس داخلی)

این جداسازی باعث میشود سیستم هم مقاومتر باشد، هم قابلگسترشتر.

6.1.1 فاز اول: Import Raw File (پردازش خام و عمومی)

در این فاز، هیچ قانون کمپینی اجرا نمیشود.

هدف فقط این است که فایل:

سالم دریافت شود
امن ذخیره شود
و به شکل قابل پردازش تبدیل گردد

گامهای اصلی این فاز به ترتیب اجرا:

۱) شروع Import توسط Process Control
فرآیند Import با یک شناسه یکتا آغاز میشود که شامل:

Mandator
Campaign
Activity

است. این شناسه بعداً برای ردیابی، گزارش و ممیزی استفاده میشود.

۲) دریافت تنظیمات Import
MaMa تمام تنظیمات لازم را از Configuration میگیرد:

کانال دریافت (ftp, http, …)
قالب فایل
فیلترهای لازم (decrypt, unzip, …)

هیچ چیزی hardcode نیست.

۳) آمادهسازی کانال دریافت (configureReceiveChannel)
در این مرحله، اتصال به دنیای بیرون شکل میگیرد:

URL
نام فایل
اعتبارنامهها
مسیرهای دسترسی

۴) آرشیو فایل خام (Archive)
قبل از هر پردازشی، فایل خام وارد آرشیو غیرقابل حذف میشود.
این آرشیو معمولاً write-once است و برای اهداف قانونی و ممیزی نگهداری میشود.

این تصمیم معماری، نقش حیاتی در قابلیت audit سیستم دارد.

۵) ساخت زنجیره فیلترها (instantiateFilterChain)
بر اساس پیکربندی، یک pipeline از فیلترها ساخته میشود؛ مثلاً:

unzip
decrypt
verify checksum

۶) اجرای فیلترها (pipes-and-filters)
فایل از این زنجیره عبور میکند تا به دادهای «خوانا و امن» تبدیل شود.

این طراحی از الگوی Pipes & Filters استفاده میکند و کاملاً پویا و قابل پیکربندی است.

6.1.2 فاز دوم: Validate & Process (اعتبارسنجی داده)

پیشنیاز:
فایل باید سالم دریافت، decrypt و decompress شده باشد.

در این مرحله:

دادهها بررسی میشوند
رکوردهای معیوب شناسایی میشوند
دادههای معتبر وارد سیستم میشوند

نکتهٔ مهم اینجاست:

مدیریت خطا فقط در صورت بروز مشکل فعال میشود
در حالت ایدهآل، ImportErrorHandler اصلاً فراخوانی نمیشود.

اما اگر خطایی رخ دهد:

خطاهای بحرانی → توقف پردازش
خطاهای سطح رکورد → ثبت، گزارش و ادامهٔ کار

این طراحی باعث میشود MaMa بتواند با دادههای «واقعیِ دنیای واقعی» کنار بیاید.

III.7 نمای استقرار (Deployment View)

«MaMa کجا و چگونه اجرا میشود؟»

7.1 نمای کلی استقرار

از همان ابتدای طراحی، یک اصل غیرقابل مذاکره وجود داشت:

هر کمپین MaMa باید روی یک ماشین مجازی اختصاصی اجرا شود.

دلایل این تصمیم:

جداسازی کامل دادهٔ Mandatorها
افزایش امنیت
سادهسازی ممیزی و حذف دادهها

پیکربندی سیستمعامل، VM و Host تأثیر مستقیمی روی امنیت کمپین دارد و باید بهطور منظم بررسی شود.

به دلیل حساسیت دادهها، جزئیات امنیتی در این مستند عمداً افشا نشدهاند.

7.2 ماشین مجازی اختصاصی برای هر کمپین

برای هر کمپین:

یک VM مجزا وجود دارد
یک دیتابیس اختصاصی
کل کد MaMa (بهجز UI پیکربندی)

هیچ اشتراکی در سطح داده یا پردازش وجود ندارد.

این طراحی هزینه را بالا میبرد، اما امنیت و شفافیت را تضمین میکند.

7.3 مخزن متادیتای مشترک (Common Metadata Store – CoMeS)

در پروژهٔ کارت سلامت آلمان، یک چالش خاص وجود داشت:
تولید Common Insurance ID (CID).

CID فقط میتوانست توسط یک نهاد دولتی تولید شود و هر درخواست باید شامل:

شناسه سازمان درخواستکننده
هدف درخواست
یک شماره ترتیبی بدون هیچ وقفه (RSN)

مشکل کجا بود؟

MaMa روی چندین VM مستقل اجرا میشد،
اما RSN باید کاملاً پیوسته و هماهنگ میبود.

راهحل معماری:

ساخت یک Common Metadata Store اختصاصی
بدون استفاده از دیتابیس عمومی
با تمرکز بر همگامسازی امن و قابل اعتماد

این یک مثال عالی از تصمیم معماری کاملاً زمینهمحور است.

7.4 ماشین پیکربندی کمپین

پس از استقرار VMها، اپراتورها نیاز دارند کمپین را پیکربندی کنند.
این کار از طریق:

یک یا چند Workstation استاندارد
با UI مبتنی بر Eclipse RCP Plugin

انجام میشود.

این UI امکان:

تعریف کمپین
تنظیم ورودی/خروجی
قوانین
فعالیتها

را بدون دست زدن به Backend فراهم میکند.

III.8 مفاهیم سرتاسری (Cross-Cutting Concepts)

«تصمیمهایی که در تمام MaMa حضور دارند»

مفاهیم سرتاسری در arc42 به آن دسته از ایدهها و الگوهایی گفته میشود که:

فقط به یک ماژول خاص محدود نیستند
در چندین بخش از سیستم تکرار میشوند
و بهشدت روی معماری، توسعه و نگهداری سیستم اثر میگذارند

در MaMa-CRM، این مفاهیم ستون فقرات معماری را تشکیل میدهند. مهمترین آنها عبارتاند از:

persistence تولیدشده از مدل دامنه
DSL برای فرمت داده
فیلترهای قابل پیکربندی
موتور قوانین برای کنترل فرآیند

8.1 Persistence تولیدشده بر اساس مدل دامنه (Generated Persistence)

یکی از جسورانهترین و در عین حال هوشمندانهترین تصمیمات معماری MaMa این است که:

تمام کد مربوط به persistence (ذخیرهسازی داده) بهصورت خودکار از روی مدل UML تولید میشود.

یعنی:

هیچ جدول دیتابیسی بهصورت دستی نوشته نمیشود
هیچ entity یا repository بهصورت دستی ساخته نمیشود
همهچیز از مدل دامنه استخراج میشود

این رویکرد باعث میشود انعطافپذیری MaMa در سطح داده به حداکثر برسد.

چرا این کار منطقی بود؟ (پیشفرضهای معماری)

این تصمیم بر اساس چند واقعیت دامنهای گرفته شد:

هر MaMa instance با دادهٔ اشخاص حقیقی (Client) سروکار دارد
همهٔ Clientها تعدادی ویژگی مشترک دارند
هر Mandator ویژگیهای اختصاصی خودش را اضافه میکند
بعضی کمپینها انواع دادهٔ کاملاً جدید دارند (مثل قرارداد بیمه یا قرارداد موبایل)
ساختار داده پس از شروع کمپین تقریباً هرگز تغییر نمیکند

نکتهٔ جالب:

در چند سال کار عملی MaMa، هیچوقت نیاز به migration دیتابیس در یک کمپین فعال پیش نیامد.

8.1.1 مدل دامنهٔ عمومی (MaMa Core Domain)

در قلب MaMa یک مدل دامنهٔ عمومی وجود دارد که همهٔ کمپینها از آن استفاده میکنند.

این مدل شامل مفاهیم پایهای است، از جمله:

Client: یک کلاس انتزاعی که نمایندهٔ یک شخص و اطلاعات تماس اوست
Contact: اطلاعات ارتباطی که در طول کمپین استفاده میشود
Next Action: نمایشدهندهٔ فعالیت بعدی در جریان کمپین

این مدل «هستهٔ مشترک» همهٔ کمپینهاست.

8.1.2 مدل دامنهٔ اختصاصی کمپین

هر کمپین، علاوه بر Core Domain، یک کپی فیزیکی از آن را به همراه توسعههای اختصاصی خودش دارد.

در این مدلها:

Client همیشه subclass میشود
روابط جدید اضافه میشوند
موجودیتهای اختصاصی دامنه (مثلاً InsuranceContract یا MobileContract) تعریف میشوند

این یعنی هر کمپین:

مدل دادهٔ خودش را دارد، اما روی یک هستهٔ مشترک سوار شده است.

8.1.3 جزئیات Code Generator

برای تولید persistence، MaMa از ابزارهای زیر استفاده میکند:

OpenArchitectureWare (OAW) برای تولید کد
Hibernate برای ORM و persistence

کد تولیدشده شامل موارد زیر است:

DDL کامل دیتابیس (schema، جدولها، indexها)
فایلهای mapping هابرنیت
متدهای campaign-specific برای جستوجو و پردازش
متدهای گزارشگیری و مانیتورینگ

محدودیتها:

ارتباطهای m:n پشتیبانی نمیشوند
تغییر ساختار داده در کمپین فعال مجاز نیست

به دلیل قراردادهای عدم افشا، نمونه کد قابل انتشار نیست.

چرا این ابزار انتخاب شد؟ (Alternative Analysis)

MaMa ابتدا از AndroMDA استفاده میکرد، اما پروژه عملاً متوقف شد
MagicDraw امکان تولید کد داشت، اما برای Hibernate بیش از حد محدود بود
در نهایت OAW بهترین توازن بین انعطافپذیری و کنترل را فراهم کرد

8.2 Import / Export CSV (نگاه کلی)

در MaMa، CSV فقط یک فرمت ساده نیست؛
بلکه بخشی از یک زبان دامنهمحور (DSL) است که تعریف میکند:

فیلدها چه هستند
ترتیبشان چیست
چگونه اعتبارسنجی میشوند
و چطور به مدل دامنه نگاشت میشوند

برای این DSL:

Parser اختصاصی نوشته شده
Editor سفارشی در Eclipse ساخته شده

(جزئیات کاملتر در نسخهٔ اصلی کتاب آمده است.)

8.3 فیلترهای فایل قابل پیکربندی (Configurable File Filters)

هر فایلی که از بیرون وارد MaMa میشود، باید از یک زنجیرهٔ فیلتر عبور کند.
این دقیقاً همان چیزی است که در Runtime View دیدیم.

دو نوع فیلتر اصلی وجود دارد:

۱) فیلترهای رمزنگاری (Encryption Filters)

سازگار با Java Cryptography Architecture
قابل استفاده با Providerهایی مثل BouncyCastle
نیازمند کلید، certificate یا credential

به دلیل حساسیت دادهها، جزئیات پیادهسازی امنیت منتشر نشده است.

۲) فیلترهای فشردهسازی (Compression Filters)

فقط الگوریتمهای بدون اتلاف (Lossless)
مثل DEFLATE (zip / gzip) یا Lempel-Ziv
بدون پارامتر پیچیده

این فیلترها بهصورت زنجیرهای و پویا پیکربندی میشوند.

8.4 موتور قوانین برای کنترل فرآیند (Rule Engine)

یکی از تفاوتهای اساسی MaMa با CRMهای سنتی، استفاده از Rule Engine واقعی است.

8.4.1 جریان اقدام (Flow of Action)

رفتار کمپینها با قوانین تعریف میشود، نه با if/elseهای سختکد شده.
این یعنی:

تغییر رفتار بدون redeploy
امکان تنظیم سریع کمپین
جداسازی منطق کسبوکار از کد

8.4.2 Drools بهعنوان Rule Engine

MaMa از Drools (متنباز) برای تعریف و اجرای قوانین استفاده میکند.

ویژگیهای کلیدی:

قوانین بهصورت فایل متنی تعریف میشوند
در زمان اجرا تفسیر میشوند
بدون نیاز به کامپایل کل سیستم

قالب قوانین بسیار ساده است:

when <A> then <B>

که در آن A و B عبارات جاوایی هستند.

⚠️ نکتهٔ مهم معماری:

قوانین اشتباه میتوانند یک کمپین فعال را مختل کنند؛
به همین دلیل تست قوانین قبل از اجرا الزامی است.

III.9 تصمیمات معماری (Architecture Decisions)

«چند تصمیم کلیدی که سرنوشت MaMa را ساخت»

هر سیستم بزرگ، چند تصمیم دارد که اگر اشتباه گرفته شوند، کل محصول را زمین میزنند.
در MaMa-CRM هم چند تصمیم خیلی تعیینکننده وجود داشت؛ تصمیمهایی که مستقیماً از نیازهای کیفیتی سیستم (خصوصاً انعطافپذیری و کارایی) آمدهاند.

۱) استفاده نکردن از ابزارهای CRM تجاری

تیم MaMa از همان ابتدا تصمیم گرفت هیچ CRM تجاری آمادهای را بهعنوان پایهٔ سیستم انتخاب نکند.

دلیلش ساده ولی حیاتی بود:

سطح انعطافپذیری موردنیاز برای راهاندازی سریع کمپینها، با معماری CRMهای آماده سازگار نبود.

این تصمیم بعداً ثابت کرد درست بوده؛ چون رقبای اولیهای که سعی کردند با «کمی دستکاری» روی CRMهای استاندارد وارد این بازار شوند، عملاً شکست خوردند و نتوانستند وارد فضای عملیاتی شوند که MaMa در آن کار میکرد.

۲) انتخاب JBoss Drools برای پردازش قوانین

MaMa برای کنترل منطق کمپینها و تصمیمگیریهای فرآیندی، به یک Rule Engine واقعی نیاز داشت. انتخاب نهایی:

JBoss Drools

تیم گزینهٔ دیگری مثل Python/Jython را هم بررسی کرد، اما نتیجه واضح بود:

برای نوع پردازش MaMa، Jython بیش از حد کند بود
Drools هم سریعتر بود و هم برای مدل «قوانین قابل تغییر در زمان اجرا» مناسبتر

این تصمیم کاملاً با نیاز انعطافپذیری و تغییر سریع قوانین کمپین همراستا بود.

۳) عدم استفاده از ابزار ETL برای Import داده

خیلیها در چنین سیستمهایی سراغ ETL میروند؛ اما MaMa این کار را نکرد.

علت اصلی، فنی نبود؛ اقتصادی و سازمانی بود:

شرکت InDAC حاضر نشد هزینهٔ لایسنس ابزارهای ETL تجاری را بپذیرد،
پس تیم حتی فرصت ارزیابی جدی آنها را هم نداشت.

در نتیجه Import/Export در MaMa بهصورت داخلی و با DSL و pipelineهای قابل پیکربندی ساخته شد—که البته در نهایت به انعطافپذیری بالاتری هم منجر شد، ولی با هزینهٔ پیچیدگی توسعه.

III.10 نیازمندیهای کیفی (Quality Requirements)

«کیفیت یعنی چیزی که قابل اندازهگیری باشد»

MaMa فقط نمیگوید “سیستم باید منعطف باشد”.
این سیستم کیفیت را به سناریوهای عملیاتی تبدیل کرده؛ یعنی چیزی که بتوان با آن تست کرد، سنجید و الزام ایجاد کرد.

سناریوهای انعطافپذیری (Flexibility Scenarios)

هدف اصلی این سناریوها این است که MaMa بتواند بدون برنامهنویسی و در زمان کوتاه، فرمتها را تغییر دهد یا فرمت جدید اضافه کند.

در MaMa معیار مشخص است:

هر فرمت جدید باید در زمان پیکربندی کمپین (CCT) و حداکثر ظرف ۲ ساعت قابل راهاندازی باشد.

این الزام برای همهٔ حالتها تعریف شده است:

اضافه کردن فرمت جدید برای Import از نوع CSV
اضافه کردن فرمت جدید برای Import از نوع Fixed-Field
اضافه کردن فرمت جدید برای Import از نوع XML
اضافه کردن فرمت جدید برای Export از نوع CSV
اضافه کردن فرمت جدید برای Export از نوع Fixed-Field
اضافه کردن فرمت جدید برای Export از نوع XML

و یک شرط جدی هم دارد:

مستند فرمت باید وجود داشته باشد
حداقل ۱۰ رکورد دادهٔ تست متنوع باید ارائه شود

این یعنی انعطافپذیری «شعاری» نیست؛ یک قرارداد عملیاتی دقیق است.

سناریوهای کارایی زمان اجرا (Runtime Performance Scenarios)

MaMa باید در مقیاس واقعی کار کند. دو الزام اصلی عملکرد:

پردازش کامل ۲۵۰٬۰۰۰ سند اسکنشده در ۲۴ ساعت
این شامل:

CSV
و تصاویر به صورت فایلهای جدا
است.

اگر بخواهیم به زبان ساده تبدیلش کنیم:

یعنی سیستم باید به طور متوسط حدود ۳ سند کامل در ثانیه را از ابتدا تا انتها پردازش کند.

پردازش کامل ۱۰۰٬۰۰۰ رکورد CSV در کمتر از ۳۰ دقیقه

این یعنی تیم معماری از ابتدا پذیرفته که “کمپینها حجیماند” و سیستم باید روی throughput طراحی شود.

سناریوهای امنیت (Security Scenarios)

سه الزام امنیتی کلیدی:

جداسازی کامل دادهها بین Mandatorها
هیچ دادهای از یک Mandator نباید برای Mandator دیگر قابل دسترس باشد. این همان دلیل VM و DB جداگانه برای هر کمپین است.
قابلیت ممیزی سریع دادههای آرشیوی
MaMa موظف است تمام دادههای ورودی (فایلها/پیامها) را برای بازهٔ زمانی مشخص (معمولاً ۹۰ تا ۱۸۰ روز پس از پایان کمپین) نگه دارد.
و اگر ممیز بخواهد، سیستم باید:

حداکثر ظرف ۹۰ دقیقه همهٔ دادههای آرشیو را قابل دسترسی کند.

انطباق با PCI-DSS در صورت وجود دادهٔ مالی
اگر کمپینی اطلاعات بانکی/کارت اعتباری داشته باشد، پردازش و نگهداری باید مطابق PCI-DSS انجام شود.

III.11 ریسکها (Risks)

«چیزهایی که اگر اصلاح نشوند، دیر یا زود ضربه میزنند»

این بخش از آن قسمتهایی است که تیم معماری واقعاً شفاف حرف زده—و این دقیقاً همان چیزی است که arc42 دوست دارد: واقعیت، نه تبلیغ.

۱) Receiver یک نقطهٔ درد مزمن است

کامپوننت Receiver به دلیل اینکه در طول زمان توسط چند توسعهدهنده و بدون هماهنگی رشد کرده، بیش از حد پیچیده و درهم شده است.

نتیجه عملی:

از همان روزهای اول، بیشتر باگهای پروداکشن از همین بخش آمدهاند.

این یعنی Receiver از نظر معماری «نیاز به بازطراحی یا refactor سنگین» دارد.

۲) انعطافپذیری زیاد، ریسک رفتار اشتباه

این سیستم عمداً runtime-configurable است. ولی یک مشکل بزرگ دارد:

هیچ بررسی/اعتبارسنجی جدی برای پیکربندیها وجود ندارد

پس ممکن است:

سیستم اشتباه کار کند
و این اشتباه حتی دیر تشخیص داده شود

بدتر از آن:

یک ادمین بدخواه میتواند هر لحظه سیستم را misconfigure کند.

۳) پیکربندیها آرشیو نمیشوند

یکی از خطرناکترین ریسکها:

تنظیمات کمپینها نسخهبندی و آرشیو نمیشوند
ممکن است تنظیمات درست گم شوند
و هیچ راه برگشتی به “آخرین پیکربندی سالم” وجود نداشته باشد

برای سیستمی که همه چیزش configuration است، این یک ضعف جدی است.

۴) Common Metadata Store ناکارآمد است

CoMeS یک راهحل ساده و سریع برای همگامسازی RSN بود، ولی مشکلاتش واضح است:

ساده و ابتدایی است
منابع را هدر میدهد
و باید سریعاً با یک سیستم درستتر جایگزین شود

پیشنهاد خود متن هم روشن است:

بهتر است با یک مکانیزم async / event-based جایگزین شود.

سخن پایانی

با رشد سیستمهای سازمانی پیچیده، برونسپاری فرآیندها، کمپینهای دادهمحور و معماریهای منعطف مبتنی بر پیکربندی، داشتن یک مستند معماری شفاف و استاندارد دیگر یک گزینهٔ لوکس نیست؛ یک ضرورت عملیاتی است. نمونهای مثل MaMa-CRM نشان میدهد که arc42 فقط برای سیستمهای آموزشی یا کوچک نیست، بلکه میتواند ستون فقرات مستندسازی معماری سامانههای بزرگ، حساس و چندسازمانی باشد—از CRMهای مبتنی بر کمپین گرفته تا پلتفرمهای دادهمحور در مقیاس ملی.

arc42 کمک میکند تصمیمات معماری، نیازمندیهای کیفی، محدودیتها، ریسکها و منطق طراحی سیستم بهصورت ساختیافته، قابل فهم و قابل انتقال مستند شوند؛ بهگونهای که هم تیم فنی، هم ذینفعان غیر فنی و هم تیمهای آینده بتوانند به یک درک مشترک برسند. همین شفافیت است که نگهداری، توسعه و تکامل سیستم را در بلندمدت ممکن میکند.

اگر در پروژههای خود با چالشهایی مثل پیچیدگی معماری، نبود مستند قابل اتکا، یا نیاز به استانداردسازی طراحی سیستم مواجه هستید، تیم معماری و توسعهی نرمافزار شرکت راهکار نگار هوشمند (آرکان) میتواند از تحلیل معماری موجود تا تدوین مستند arc42 و همراهی در پیادهسازی عملی، کنار شما باشد.

این مقاله با هدف آگاهیبخشی و انتقال تجربهی معماری، توسط تیم توسعهی نرمافزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.

#معماری_نرمافزار
#arc42
#مستندسازی_معماری
#CRM
#enterprise_architecture
#تحلیل_سامانه
#طراحی_سیستم
#معماری_فنی
#Software_Architecture
#architecture_documentation
#distributed_systems
#quality_attributes
#technical_writing
#شرکت_راهکار_نگار_هوشمند
#arcanco