مفاهیم
برای طراحی نرم افزار های بزرگ و پیچیده و هدف اصلیش اینه بیزینس رو مدل سازی کنه ، جوری که پروداکت و دولوپ همزبان شن
راهکار هایی واسه پروژه های اینترپرایز می ده از جمله جدا سازی دامین ها به بخش های کوچک تر برای راحت کردن کار ،
توجه شود دنبال اینیم که بیزینس و مفاهیم و روند رو مدل سازی کنیم و نه به معنای این که مدل دیتابیس رو دربیاریم ،
توجه شه اگر بدون درگیر کردن دیتابیس و ریلیشن ها ، تنها بیزینس رو بفهمیم ، زبان مشترک -Ubiquitous Language - رو با تیم بیزینس در بیاریم و بتونیم دامین ها و موجودیت ها رو در بیاریم
نتیجه ی رعایت کردن DDD
-
نتیجش میشه که کد ها خیلی تفکیک بهتری داره ، و اینکه جاهایی که ۵۰ - ۵۰ هست که یه مورد تو این دامین باشه یا دامین دیگه ، با ddd مشخص میشه.
-
معمار اگه بیزینس رو بفهمه میتونه با دقت خیلی بالایی دامین ها رو تفکیک کنه جوری که توسعه و نگه داری برای آینده سخت نباشه+
-
domain
مفهوم اصلی بیزینس که به صورت یک سیستم یا یک سرویس پیاده سازی می شود
مثلن توی مانی ، یه سیستم که خدمات مالی میده
توجه شه یه کسب و کار تنها یک دامین داره
- bounded context:
از دید پیادهسازی تعریف میشه
مرزهای زمینه به این کمک میکند که مدلهای پیچیده دامنه در بخشهای جداگانه و مشخص تعریف شوند، تا از پیچیدگیها و تداخلها جلوگیری شود.
- subdomain
از دید کسبوکار تعریف میشه
بخش های کوچک تری که در دامین هستند و خودمون باید بخش بخش کنیم
مثال: در همان صرافی ارز دیجیتال:
زیر دامنه تریدینگ شامل مدلهایی مثل سفارشها، معاملات و مشتریها است.
-
سوال مهم
تفاوت subdomain و bounded context در چیست؟
جواب : Subdomain از دید کسبوکار تعریف میشه، نه از دید پیادهسازی در حالی که bounded context از دید پیادهسازی تعریف میشه، نه از دید کسبوکار
Domain: «فروشگاه آنلاین»
Subdomains (از دید کسبوکار):
Ordering → ثبت و مدیریت سفارش
Payment → پردازش تراکنشها
Inventory → مدیریت موجودی
Shipping → ارسال کالا
Bounded Contexts (از دید پیادهسازی):
Ordering BC → پیادهسازی Subdomain سفارش
Payment BC → پیادهسازی Subdomain پرداخت
Inventory + Shipping BC → ممکنه این دو Subdomain توی یک سرویس ترکیب بشن
Auth BC → یک BC که Subdomain خاصی نیست و فقط پشتیبان سیستم است
core domain :
مسعله ی اصلی بیزینس و کسب و کار مصلن توی مانی ، سرویس loan دامین است در حقیقت رسالت بیزینس ، دامین هست
فضایی که بیزینس ما قراره پیاده سازی کنه ( مثلا بیزینس ما فروشگاهه یا سیستم حساب داریه ) در حقیقت هدف اصلی بیزینس ، دامین ماست .
Ubiquitous Language :
یک زبان مشترک بین بیزینس و دولوپ هاست که به طور مشترک به آن اشاره می کنند و این زبان در مستندات ، در کد و در همه ی نام گذاری ها رعایت میشود.
مثل “سفارش”، “معامله”، “کیف پول” و “liquidity” باید معنای دقیقی برای همه داشته باشند.
مثلا اگر در بیزینس میگیم “سفارش”، توی کد هم همون Order استفاده بشه نه Transaction یا Req.
Entities
مشخصه دیگه ، موجودیتها اشیایی هستند که هویت خاص دارند و این هویت برایشان مهمتر از ویژگیها یا خصوصیاتشان است.
هویت یعنی میشه ID براشون در نظر گرفت ، مثلا یک شخص حتی اگه شماره تلفنشم عوض کنه ، بازم همون هوییت رو داره ، حتی این کاربر ما اگه اسم و فامیلشم عوض کنه ، بازم ثابته و ID تغییر نمیکنه پس انتیتی هست
Value Objects :
مقادیری هستند که هویت خاصی ندارند و میتوانند به صورت مستقل از هویتهای دیگر وجود داشته باشند.
مثلا یه آدرس ، به هیچ وجه تغییر پذیر نیست ، مثلن یه آدرس یه خطی اگه کوچیک ترین بخشیش تغییر کنه ، دیگه یه آدرس دیگست
- سوال : Immutable بودن Value Object چرا مهم است؟
چون باعث میشود قابل اعتماد باشد، Thread-safe باشد، و بتوان به راحتی از آن در ساختارهای داده و کش استفاده کرد.
Aggregates
مجموعهها یک ساختار داده است که شامل یک یا چند موجودیت است. اما خود یک واحد یا یک موجودیت هستند
مثلن یک سفارش شامل چندین قلم جنس میباشد
Factories :
ساختن موجودیت های پیچیده و چند مرحله ای رو انجام میده ولی تضمین می کنه که صحیح باشه
فرض کنید برای ثبت سفارش ، چند استپ داریم. اول باید سفارش را ثبت کنیم، سپس قلمها را به سفارش اضافه کنیم و در نهایت پرداخت را انجام دهیم.
Repositories :
مکانی که داده رو در آن ذخیره می کنیم و راحت داده رو پیدا می کنیم
اگه در ابعاد کد نگاه کنیم پرسیستنس استوریج ها هست
Services :
مجموعه ای از فعالیت هایی هستند که به صورت مستقل از موجودیت ها انجام می شوند
یه جورایی اگه از دید کد نگاه کنیم همون لاجیک یا یوزکیس هست
بیشتر و پیشرفته تر
اینا خیلی عمیق ترن و نیازی به مطالعه برای مصاحبه ندارن
ساب دامین : باید بیزینس را به بخش های کوچک تر تقسیم کنیم ، مانند بخش فروش ، بخش سفارش گیری و … به هر کدام ساب دامین گفته می شود .
ساب دامین به ۳ نوع تقسیم می شه :
این هسته مرکزی بیزینس است ، بهتر است نیرو های خبره خود را در اینجا بهع کار گیریم
supporting subdomain :
اهمییت نوع اول را ندارند ولی باید وجود داشته باشند تا کار جلو بره
generic subdomain :
می تونیم از ابزار یا پکیج ها هم استفاده کنیم
bounded context :
برای جدا سازی بخش های کد از این پترن استفاده می کنیم ، این پترن می شگه کد یا دیتا بیس هر بخش باید جدا بشه ، خیلی شبیه به سرویس های میکرو سرویس است
context map pattern :
این پترن در مورد روابط بین باندد ها و نحوی ارتباط و تعامل الگو هایی دارد و ۷ نوع ارتباط داریم :
shared kernek : در این حالت می گه باندد ها از منابع مشترک استفاده کنن، این خطرناکه زیرا اگه یه تیم اونو تغییر بدن ، تیم دیگه باید کاملا آماده باشه
customer / supplier : یه باندد داره یه طرفه به یه باندد دیگه خدمات می ده
anticorruption layer pattern : در این الگو نحوه ی تعامل آپ استریم و داون استریم از طریق یک ترجمه گر یا ترنسلیشن انجام میشه و آپ استریم آن را بروز می کند و مستقل از داون استریم است مانند پروتوباف در جیار پیسی