سند چشم انداز دامنه

در شروع پروژه هیچ Model سازی انجام نشده و معمولا توسعه پروژه با یک Model ابتدایی شروع می شود. اما معمولا پروژه های نرم افزاری به مرور زمان بزرگ و پیچیده می شوند. در یک پروژه بزرگ و پیچیده افراد به راحتی دچار درسردرگمی می شوند و مسیر توسعه را اشتباه پیش می برند بدین ترتیب که ممکن است تمرکز خود را به جای اینکه بر روی مزیت رقابتی Domain صرف کنند، بر روی جزییات به ظاهر مهم اما در اصل بی اهمیت هزینه کنند. تمام ضینفعان پروژه از ابتدای مسیر باید بدانند پروژه نرم افزاری برای چه هدفی ایجاد شده و قرار است چه ارزش افزوده ای را به سازمان اضافه کند. با دانستن این مورد است که تمام افراد در طول عمر پروژه نرم افزاری می دانند بر کدام قسمت های مدل کسب و کاری باید تمرکز بیشتری داشته باشند و بیشترین تالش را در آن قسمت انجام دهند. برای این منظور میتوان، سند چشم انداز دامنه (Domain Vision Statement) تعریف کرد.

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

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

Eric Evans توصیه می کند این سند را خیلی خالصه در حد یک صفحه بنویسید و در آن درباره Core Domain و ارزش افزوده ای که به سازمان اضافه می کند توضیح دهید. از توضیح دادن درباره جزییات و هر آن چیزی که خارج از Core Domain است بپرهیزید. توضیح دهید چگونه Core Domain به نیاز های مختلف پاسخ میدهد. از همان ابتدا با شروع پروژه این سند را تهیه کنید و همچنان که در طول پروژه دید عمیق تری نسبت به دامنه کسب و کار پیدا می کنید این سند نیز باید بروز شود.

مستند سازی دامنه

شما می توانید فرآیند تقطیر دامنه را به خوبی انجام دهید، انواع Subdomain های پروژه را شناسایی کنید، Bounded Context ها و مرز بین آنها را به درستی تشخیص دهید و مدل سازی کنید و خیلی خوب به Core Domain مسلط باشید، اما آیا پروژه نرم افزاری توسعه داده شده هم به خوبی تمام این موارد را نشان می دهد؟

نتیجه فرآیند تقطیر سازی چندین Subdomain است که هر کدام شامل چندین Bounded Context می شوند هر Bounded Context شامل چند Module و هر Module شامل چندین Component است. پس تعداد اجزای تشکیل دهنده بسیار زیاد هستند. یکی از Sub Domain های شناسایی شده در فرآیند تقطیر، Core Subdomain است، که اگر در پروژه توسعه داده شده قابل تشخیص نباشد به راحتی بین آن همه اجزای تشکیل دهنده پروژه نرم افزاری دفن و غیر قابل شناسایی می شود. بنابراین در پروژه نرم افزاری در حال توسعه باید طوری Core Domain را پیاده سازی کنید تا از باقی Subdomain ها قابل تشخیص باشد. اگر توسعه دهندگان در پروژه نرم افزاری قادر به تشخیص Core Domain نباشند در واقع قادر به تشخیص نیستند که چه بخشی در پروژه از اهمیت بیشتری برخوردار است و باید بیشترین تالش خود را در کدام قسمت ها بگذارند. در نتیجه در چنین شرایطی توسعه دهندگان به همان میزان زمانی که صرف توسعه Generic Subdomain می کنند به همان میزان برای Core Domain هزینه میکنند. خب قاعدتا اهمیت Core Domain بسیار بیشتر از Generic Domain است پس اگر برای هر دو بخش به یک اندازه هزینه کنید یعنی در حال هدر دادن سرمایه های پروژه هستید و به احتمال زیاد این پروژه نرم افزاری با شکست مواجه خواهد شد.

Eric Evans برای جلوگیری از این مشکل تکنیک Highlighted Core را معرفی کرده است. او می گوید در هنگام پیاده سازی و توسعه پروژه ساختار پروژه را طوری طراحی و پیاده سازی کنید که Core Domain از باقی قسمت ها به راحتی قابل تشخیص باشد به طوری که وقتی یک توسعه دهنده جدید به تیم اضافه می شود با نگاه کردن به پروژه به راحتی بتواند تشخیص دهد Core Domain کدام قسمت پروژه قرار دارد. حتی اگر با یک پروژه Legacy مواجه هستید که Core Domain قابل تشخیص نیست می توانید با ابزار هایی که در محیط توسعه در اختیار دارید Core Domain را قابل تشخیص کنید مثال می توانید در قسمت هایی که Core Domain پیاده سازی شده است با استفاده از Comment نوشتن برای دیگران مشخص کنید که این قسمت مربوط به Core Domain است. پس تا می توانید در طراحی ساختار پروژه و نام گذاری ها سعی کنید Core Domain از باقی قسمت ها به راحتی قابل تشخیص باشد.

طراحی درست ساختار پروژه و نام گذاری درست در توسعه پروژه یکی از روش های مستند کردن Core Domain است که در محیط کدنویسی قابل پیاده سازی است. روش دیگر که مکمل این روش است مستند کردن Core Domain به واسطه دیاگرام ها است. Eric Evans توصیه می کند یک سند بین 3 تا 7 صفحه از Core Domain تهیه کنید و تمام اجزای Core Domain به همراه تمام ارتباطاتی که Core Domain با باقی ِالِمان های پروژه دارد را داخل آن سند توضیح بدهید یا با ترسیم دیاگرام آن را نمایش بدهید. این دیاگرام ها میتوانند دیاگرام های استانداردی مثل UML باشند یا حتی یک دیاگرام غیر استاندارد که روی کاغذ ترسیم شده باشند. در واقع تنها چیزی که در این سند مهم است این است که Core Domain و تمام ارتباطات آن با تمام اجزای پروژه به خوبی مشخص شده باشد. اگر در طول عمر پروژه Core Domain تغییر کرد این سند نیز باید تغییر کند و تغییر در آن باید با تایید مدیران پروژه باشد و بعد از تغییر باید فورا نسخه جدید سند در اختیار تمام اعضای تمام تیم ها قرار بگیرد و به تمام آنها اطالع رسانی الزم انجام شود.

جداسازی دامنه

مستند سازی دامنه بر روی نحوه نام گذاری Core Domain در پروژه تاکیید دارد به نحوی که از اسم هر ِالِمان بتوان تشخیص داد که آن بخشی از Core Domain است. اما نام گذاری درست تا حدودی میتواند از گم شدن Core Domain در میان انبوهی از کد محافظت کند. در راستای تقطیر دامنه یک تکنیک دیگری که می تواند این محافظت را تقویت کند، جدا کردن Core Domain در پروژه از باقی قسمت ها به صورت ساختاری است.

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

با نام گذاری درست و ساختاربندی صحیح Core Domain همیشه در پروژه مشخص است که قلب تپنده پروژه کجا قرار گرفته و چه ویژگی هایی دارد و در واقع کسب و کار با استفاده از آن پروژه کدام یک از نیاز مشتریان خود را پاسخ می دهد.

مکانیزم ها در Sub Domain ها

هر Domainیی یک سری مکانیزم ها برای انجام یک سری کار ها دارد. این مکانیزم ها در داخل خود یک سری الگوریتم دارند و یا مجموعه ای از چند فرآیند پیچیده هستند تا یک هدفی را به سرانجام برسانند. برای مثال مکانیزم خواندن پیام از صف را در نظر بگیرید. این مکانیزم در دل خود یک توالی از کارها را انجام می دهد تا به یک سرور وصل شود سپس روی آن سرور به یک تکنولوژی خاصی که زیرساخت صف را فراهم می کند وصل می شود و با پروتکل ی که آن تکنولوژی معرفی کرده از صف پیام ها را دریافت کند. حال که Domain برای اهداف خود نیاز به این مکانیزم دارد آیا باید این مکانیزم در دل Doamin پیاده سازی شود؟ یا به عبارت دیگر آیا Domain باید از نحوه انجام عملیات این مکانیزم با خبر باشد؟ قطعا خیر.

هر Domain مربوط به مسئله خاص است و هر آن چیز مهمی که به آن مسئله می پردازد و شخصیت آن مسئله را شکل می دهد داخل Domain مربوطه قرار می گیرد و هر آن چیزی که در شخصیت Domain نقشی ندارد خارج از آن قرار میگیرد. پس زمانی که Domain می خواهد از این مکانیزم استفاده کند نباید بداند که این مکانیزم چگونه کار خود را انجام می دهد، بلکه فقط باید بداند چه کاری انجام می دهد. در واقع مکانیزم ها باید خارج از Domain پیاده سازی شوند و دسترسی Domain به آنها فقط از طریق Interface خواهد بود. هر Interface می تواند شامل چندین مکانیزم باشد که تمام آنها در یک زمینه خاص سرویس می دهند مثال در زمینه صف ها می توان یک Interface با دو مکانیزم خواندن از صف و نوشتن در صف داشت. همچنین اسم هر مکانیزم باید بیانگر کاری که آن سرویس انجام میدهد باشد و هیچ اشاره ای به اینکه چگونه آن کار را انجام می دهد نباید داشته باشد.

از آنجایی که Interface مکانیزم برای استفاده Domain نوشته می شود، باید این Interface را داخل Domain نگهداری کنیم. به عبارت دیگر Domain مالک این Interface است. اما از آنجایی که Domain نباید از نحوه انجام کار آن Interface نباید اطالعی داشته باشد و نباید به آن وابسته باشد پس باید پیاده سازی آن Interface را خارج از Domain انجام دهیم.

آیا می توان مکانیزم ها را از Core Subdomain به Generic Subdomain ها منتقل کرد؟ خیر. Core Subdomain و Generic Subdomain هر دو یک دامنه دارند و از لحاظ ساختار و اجزای تشکیل دهنده شبیه یکدیگر هستند، تنها تفاوت آن ها در میزان اهمیت آنها است. Core Subdomain از اهمیت بسیار بیشتری برای کسب و کار برخوردار است در حالی که اهمیت Generic Subdomain بسیار پایین تر است. بنابراین خود Generic Subdomain ها شامل یک سری مکانیزم ها هستند که باید خارج از Domain آن پیاده سازی شود. پس فارغ از آنکه مکانیزم داخل Core Subdomain استفاده می شود یا Generic Subdomian باید داخل همان Subdomain از طریق یک Interface سرویس دهی کند و Domain هیچ گاه از چگونگی انجام کار آن نباید مطلع شود.

یک استثنا وجود دارد که یک مکانیزم می تواند داخل خود domain پیاده سازی شود. اگر خود مکانیزم جزو مزیت رقابتی کسب و کار باشد، آنگاه باید داخل خود Domainپیاده سازی شود.

Domain Story Telling

در هر کسب و کاری دامنه های زیادی وجود دارد که انواع مختلفی نیز دارند مثل Core و Support و Generic و هر کدام تقسیم به چند Bounded Context می شوند که در هر کدام یک سری موجودیت وجود دارد. برخی از موجودیت ها نقش دارند و یک یا چند کار مشخص را با ترتیب مشخصی انجام می دهند و برخی دیگر از موجودیت ها اشیایی هستند که کارها روی آنها انجام می شوند.

دانش مربوط به موجودیت ها و اشیا و سناریو های ممکن در اختیار یک نفر نیست. معموال این دانش بین تمام ضینفعان پروژه مشترک است. یعنی بخشی از این دانش در اختیار مدیران کسب و کار بخشی دیگر در اختیار تیم محصول و ... است.

از آنجایی که توسعه دهنده سیستم قرار است پروژه نرم افزاری را پیاده سازی کند، باید این دانش را در اختیار داشته باشد. یک تکنیک بسیار مفید که جزو طراحی استراتژیک محسوب می شود تکنیک Domain Story Telling است. معموال از این تکنیک در مراحل ابتدایی و قبل شروع پروژه استفاده می شود تا به کمک آن بتوانند Subdomain ها، Bounded Contextها، موجودیت ها و محدودیت ها را زودتر شناسایی کنند و در نهایت Model سازی صحیح تری از کسب و کار داشته باشند.

در این تکنیک تیم محصول و تیم توسعه و در صورت نیاز مدیران مربوطه یک جلسه تشکیل می دهند و بر روی یک یا چند فرآیند کسب و کار با یکدیگر گفتوگو می کنند. در طی این گفتوگو دانش مربوط به آن فرآیندها از افراد به یکدیگر منتقل میشود و این دانش از طریق دیاگرام هایی که روی تخته ترسیم می شود به شکل ظاهری در می آید. این دیاگرام ها ، دیاگرام های رسمی مثل UML یا دیاگرام های تکنولوژیک نیستند بلکه یه نوع زبان تصویری هستند برای نمایش آن چه که در Domain توسط افراد روی اشیا اتفاق می افتد. در این زبان تصویری چهار ِالِمان طراحی وجود دارد که به واسطه آنها باید فرآیند مورد نظر را ترسیم کنید، که عبارتند از:
• بازیگر (Actor)
• شی (Work Object)
• عمل (Activity)
• ترتیب (Sequence Number)

بازیگر و شی موجودیت های Domain هستند و عمل، رفتارهای ی است که متعلق به بازیگر است و یا رخدادی است که برای یک شی اتفاق می افتد و ترتیب مشخص می کند که رفتارها با چه ترتیبی توسط بازیگر اجرا میشوند و یا رخدادها با چه ترتیبی شکل می گیرند. شما راجع به هر فرآیندی این 4 ِالِمان را مشخص کنید توانسته اید دانش خود را نسبت به دامنه تقویت کنید.

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

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

تفاوت Domain Vision State و Domain Story Telling

سند Domain Vision State ماموریت یک دامنه را مشخص می کند. شما در این سند اهمیت دامنه مورد نظر برای کسب و کار را توضیح می دهید در حالی که Domian Story Telling جزییات فرآیندهای موجود در یک Subdomain را مورد بررسی قرار می دهد. در واقع شما با استفاده از Domain Story Telling می توانید ماموریت دامنه را شناسایی کنید و سپس به کمک آن سند Domain Vision State را تولید کنید.

Event Storming

یکی دیگر از راه های شناخت بهتر Domain شناخت رخداد های ممکن در دامنه است. یعنی تمام اتفاقاتی که در یک Subdomain رخ میدهد به همراه عامل آن ها و توالی آنها را شناسایی کنید. به این تکنیک Event Storing گفته می شود. همانند تکنیک Domain Story Telling نیاز دارید تا تمام کسانی که در مورد آن Domain دانش دارند در یک جلسه دور هم جمع کنید و در مورد رخدادهای آن Domain با یکدیگر گفتوگو و بحث کنید یا به عبارت دیگر یک طوفان فکری درباره تمام رخدادهای ممکن راه بیاندازید.

ِالِمان های تشکیل دهنده:
Event: یک اتفاقی که در دامنه رخ میدهد
Command: عاملی که یک Event را شکل می دهد
Aggregate: عاملی که Event را مدیریت می کند
Policy: دستورالعمل بعد از رخداد Event
Hotspot: چیزهایی که در فرآیند Event Storming برایمان نامشخص هستند

برای مدیریت بهتر این ِالِمان ها بهتر است از برگه های کوچک رنگی بر روی تخته استفاده کنید. معموال Event ها را با رنگ زرد، Command ها با رنگ نارنجی، Aggregate ها با رنگ سبز، Policy ها با رنگ آبی و Hotspot ها با رنگ قرمز مشخص می شوند. همچنین برای این کار ابزارهای آنالینی وجود دارند که این کار رو برای شما آسان تر می کنند.

برای شروع ابتدا تمام Event های ممکن را شناسایی کنید و طبق یک خط زمانی از چپ به راست آنها را بچینید، زمان وقوع Event ها همیشه در گذشته است پس تمام Event باید فعل گذشته داشته باشند، سپس از انجایی که هر Event توسط یک Command به وجود می آید، شروع به شناسایی Command هر Event کنید. Command هر Event را پشت سر آن قرار دهید. زمان هر Command باید زمان حال باشد. سپس شروع به شناسایی Aggregate ها کنید. تمام Event ها و Command ها یک موضوعیتی دارند مثال سفارش، مشتری. برای مثال بهتر فرض کنید یک Command داریم با عنوان "سفارش ثبت می شود" و یک Event برای آن داریم با عنوان "سفارش ثبت شد"، موضوعیت این دو "سفارش" هستند پس سفارش، Aggregate مربوط به این دو میباشد. پس از شناسایی Aggregateها آنها را میان Command ها و Event ها قرار دهید. قاعدتا بعد از هر Event باید یک Command دیگر اجرا شود تا فرآیند به مرحله بعدی برود اینکه مرحله بعدی چه چیزی باید باشد توسط Policy مشخص می شود و این Policy خود یک Command دیگر را اجرا می کند. و در نهایت چیزهایی که برای شما نامشخص هستند را به صورت Hotspot در نظر بگیرید تا در جلسات بعدی بتوانید با تبادل دانش بیشتر آنها را حل کنید.

در انتهای این جلسه شما موفق به شناسایی تمام Event ها، Command ها، Aggregate ها و Policy های موجود در یک Domain شده اید و با دانش عمیقی که به دست آورده اید می توانید Subdomain ها، Bounded Context ها، مرز و نحوه ارتباط بین Bounded Context ها را صحیح تر شناسایی کنید.

تفاوت Event Storming و Domain Story Telling

تکنیک Domain Story Telling بر روی فرآیندها و آدم هایی که آن فرآیندها را انجام می دهند تمرکز دارد در حالی تکنیک Event Storming خیلی جزیی تر دامنه را هدف قرار می دهد و تمرکز اصلی آن روی رخداد ها است. به عبارت دیگر می توان گفت Domain Story Telling حالت داستان سرایی دارد و بیشتر روی بخش توضیح کسب و کاری یک Domain تمرکز دارد و کمک می کند آن Domain را بهتر درک کنید اما Event Storming بیشتر جنبه فنی دارد و کمک میکند تا پیاده سازی صحیح تری از Domain داشته باشید.

Example Mapping

یکی دیگر از تکنیک هایی که کمک به شناخت بهتر دامنه و پیاده سازی صحیح آن می کند Example Mapping است. شما به کمک این تکنیک میتوانید قوانین موجود در دامنه را شناسایی کنید و با نوشتن مثال های متنوع آن قوانین را به راحتی درک کنید. این تکنیک جزو تکنیک های معرفی شده در DDD نیست اما استفاده از آن میتواند در شناخت دامنه کمک قابل توجهی کند.

برای شروع استفاده از این تکنیک نیاز به شناسایی User Story های دامنه دارید. اما User Story چیست؟
User Story تعریف کوتاهی است از کاری که یک کاربر می خواهد توسط قابلیت هایی که در کسب و کار ما وجود دارد انجام دهد و در قبال آن یک ارزشی برای آن کاربر ایجاد می شود. هر User Story یک انجام دهنده کار دارد که یک نقشی را در کسب و کار ایفا می کند مثال مشتری، مدیر کسب و کار، مسئول انبار و ... ، یک کار مشخصی دارد که با انجام شدن آن یک ارزش مشخصی برای کاربر انجام دهنده ایجاد می شود.

برای استفاده از این تکنیک افراد تیم در یک اتاق کنار هم قرار جمع می شوند که حتما در افراد حاضر باید حداقل یک تحلیلگر، یک توسعه دهنده و یک تستر وجود داشته باشد حضور باقی افراد در صورت نیاز باالمانع است. این تکنیک 4 ِالِمان دارد و هر کدام با یک رنگ مشخص میشوند:
• User Stroy: رنگ زرد
• قوانین: رنگ سبز
• مثال: رنگ آبی
• سوال یا ابهام: رنگ قرمز

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

مدت جلسه برای هر User Story بهتر است نهایتا 30 دقیقه باشد. اگر در 30 دقیقه جلسه نتیجه ای نداشت میتوانید جلسه دیگری برنامه ریزی کنید و تا آن جلسه دیگر پاسخ کارت های قرمز را نیز پیدا کنید. اگر تعداد قوانین زیاد شد و یا تعداد سناریو های مختلف برای مثال ها زیاد شد تا جایی که یک جلسه برای آن کافی نبود بهتر است در صورت امکان آن User Story را به چند User Story دیگر تقسیم کنید.

در اتمام هر جلسه افراد حاضر در جلسه نسبت به دامنه دید عمیق تری پیدا کرده اند و همچنین نیروهای توسعه دهنده بهتر می توانند برای پ یاده سازی این User Story زمان بندی دقیق تری ارائه دهند.

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

ارتیاط Domain Story Telling و Event Storming و Example Mapping

هر سه تکنیک برای شناخت بهتر دامنه استفاده می شوند اما شما می توانید به انتخاب خود از هر کدام که تشخیص دادید استفاده کنید. در واقع اجباری برای استفاده از هر سه تکنیک در DDD وجود ندارد. این نوع تصمیمات بستگی به شرایط پروژه و کسب و کار دارد که معمار سیستم با در نظر گرفتن این شرایط در مورد انتخاب تکنیک های استراتژیک تصمیم گیری می کند.

اگر بودجه و زمان کافی دارید، استفاده از هر سه تکنیک به صورت جداگانه، کمک زیادی به شناخ ت بهتر دامنه میکند.
با استفاده از Domain Story Telling فرآیندها و هدف هر دامنه را شناسایی کنید.
با استفاده از Event Storming رخداد ها، دستورات مربوط به ایجاد رخداد ها و سیاست های دامنه ها را شناسایی کنید.
با استفاده از Example Mapping ارزش هایی که هر دامنه برای کاربران مختلف با رعایت قوانین کسب و کاری به ارمغان می آورد را شناسایی کنید.

Core Domain Rafactoring

تکنیک هایی که تا به اینجا مورد بررسی قرار دادیم کمک به پیاده سازی بهتر Core Domain و حفظ انسجام آن در پروژه می کند. حال اگر با پروژه ای روبرو شدید که از این تکنیک ها برای پیاده سازی Core Domain استفاده نشده بود و با یک Core Domain ضعیف روبرو بودید باید با استفاده از این تکنیک ها سعی کنید تا انسجام را به آن بازگردانید و نسخه بهتری از Core Domain را در پروژه پیاده سازی کنید.

برای شروع ریفکتورینگ پروژه بهتر است از یکی از دو مورد زیر شروع کنید:
• اگر پروژه با مشکالت جدی روبرو است، به دنبال ریشه مشکالت باشید. اگر ریشه مشکل در Core Domain یا در ارتباطات بین Core Domain با باقی قسمت ها بود، برای حل مشکل، ریفکتورینگ را از همین نقطه شروع کنید.
• اگر مشکل جدی گریبان گیر پروژه نیست و می توانید ریفکتورینگ را از هر قسمت شروع کنید، بهتر است سراغ Core Domain بروید و سعی کنید با تکنیک جداسازی دامنه نسخه بهتری از آن را پیاده سازی کنید یا به سراغ Supporting Subdomain هایی بروید که می توانند به عنوان Generic Subdomain در پروژه پیاده سازی شوند.

آیا نیاز به توضیح بیشتری در مورد هر یک از این تکنیک‌ها یا نحوه پیاده‌سازی آن‌ها دارید؟