نحوه کار با با Entity هایی که اگریگیت روت نیستن
سلام
استاد میخواستم بدونم، اینکه ما بیایم برای یه انتیتی که خودش اگریگیت روت نیست، یه ریپوزیتوری بسازیم و بتونیم تو دیتابیس اددش کنیم و اپدیتش کنیم و … کار اشتباهیه؟
بر خلاف DDD هست؟
چون مثلا من برای همون جدول رنگ های Inventory، اومدم کلا یک Aggregate جدا ساختم براش، و کارش جدا از Inventory هست کلا، این کار درسته؟
نمیشد این انتیتی Color عضو همون Inventory Aggregate باشه، ولی مثلا تو پنل ادمین یه قسمت جدا بزارم براش، از اونجا ادمین بتونه رنگ هارو اضافه کنه و …؟
بعد اونطوری من باید داخل ریپوزیتوریه Inventory مثلا متودی های AddColor, EditColor, RemoveColor رو میساختم؟ اون کارم اشتباهه؟
کلا یخورده گیج شدم چی درسته چی غلطه، میشه این اجزاء اگریگیت رو جدا باهاشون کار کرد، یا اشکال نداره توی ریپوزیتوریه اگریگیت روته خودش چند تا متود اختصاصی خودش رو داشته باشه، کلا چجوری باید رفتار کرد با انتیتی هایی که اگریگیت روت نیستن و فقط عضوی از یه اگریگیت هستند؟
پاسخ ها
bzmind
الان مثلا من میخوام برای قسمت ShippingMethod ها، یه جدول تو پنل ادمین باشه که ادمین بتونه روش های مختلف ارسال سفارش + قیمت هاشون رو مشخص کنه، بعد موقع ثبت سفارش بیام اون روش های ارسال رو نشونش بدم، حالا نمیدونم اصن این کاریه که تو پروژه های واقعی میکنن یا نه، اون رو هم اگه میشه بگید چجوریه، ولی حالا فرض کنید من میخواستم یه همچین کاری بکنم، که ادمین تو پنل اضافه کنه روش های ارسال رو،
خب الان من باید این ShippingMethod رو کلا یه اگریگیت جدا بکنم؟
یا توی اگریگیت Order باشه، ولی یه سری متود های خاص خودش رو هم توی ریپوزیتوریه OrderRepository داشته باشه؟
چون این هم یجورایی شبیه به همون قضیه رنگ های Inventory هست، من گفتم این هی میخواد توی سیستم من اتفاق بیفته، بیام روش درست انجام این کار رو بپرسم که چجوری برخورد کنیم اینجور مواقع.
محمد اشرافی
سلام
کار اشتباهی ه و نباید این کار رو انجام داد ( برای Query گرفتن مشکلی نداره )
قوانین مهم Aggregate :
Aggregate root باید به تمام child ها دسترسی داشته باشه و مدیریتشون کنه ، هیچ کس جز Aggregate Root به Child های خودش دسترسی نداره و اصلا بدونه root وجود خارجی ندارن
یک Aggregate همیشه باید به صورت کامل لود بشه ( برای بحث Query زدن کلا فرق داره ، Query اصلا ربطی به DDD و قوانین کسب کارمون نداره)
----------
توی این پروژه خودمون Color یه Aggregate کاملا جداست ، ولی ممکنه توی یه پروژه دیگه به یه شکل دیگه باشه ، اصلا ممکنه با Inventory برن توی یه Aggregate
برای ShippingMethod هم درسته ، یه Aggregate جدا میخواد ، و ادمین مشخص شون میکنه بعد موقع نهایی سازی سفارش ، کاربری یکی از اونارو انتخاب میکنه و اطلاعاتش توی order ذخیره میشه
-------------------------------------------------------------------------------------
هیچ راه ثابتی برای تشخیص Aggregate وجود نداره که بهتون بگم ، برای تشخیص aggregate ها به روند ساخته شدن Entity ها توجه کنید ، اونایی که توی یک Transaction باید ساخته بشن ، به احتمال 90 % می تونن توی یه Aggregate باشن ( بستگی به پروژه هم داره ) ، یا باید به Invariant های یه Entity توجه کنید و وابستگی هاشو جمه کنید یه جا
bzmind
ممنون استاد، بعد الان که ShippingMethod رو یه اگریگیت جدا کردم، البته اسمش Shipping هست، الان باید اطلاعات شیپینگ رو داخل order یجورایی کپی کنم دیگه درسته؟ مثلا در آینده ما بخوایم قیمت یه Shipping رو عوض کنیم، سفارش هایی که ارسال شدن و تو راه هستن که دیگه نباید قیمت Shipping هاشون برای یوزر تغییر کنه نه؟
چجوری این کارو باید کنم؟ من توی متود CheckOut اومدم یه ShippingMethodId گرفتم، بعد این رو با یه OrderDomainService میخوام از دیتایس اطلاعاتش رو بگیرم، بعد توی 2 تا پراپرتی به اسم ShippingCost, ShippingMethod اسم و قیمت اون Shipping رو سیو میکنم توی Order، این کار درسته؟
بعد توی OrderDomainService من اگر بیام از ریپوزیتوریه اگریگیته Shipping استفاده کنم، اشکالی نداره؟ ینی توی یه DomainService میشه از ریپوزیتوری های اگریگیت های دیگه استفاده کرد؟
محمد اشرافی
با هر روشی می تونید پیاده سازیش کنید ، ولی من ترجیح میدم به همین شکلی که هست انجام بشه ( توی order یه ValueObject بزارم برای ShippingMethod و موقع checkout اطلاعات رو دریافت میکنم )
درمورد سوال بعدیتون هم باید بگم ، نه مشکلی نداره ، کلا ماهیت DomainService همینه ، وقتی می خواید یه کاری انجام بدین ولی وابسته به یه aggregate دیگه است ، یا باید با دیتابیس ارتباط داشته باشید یا … از DomainService استفاده میشه
bzmind
بعد شما قیمت هر روش ارسال و اسمو ایناشو کجا توی سیستم ذخیره میکنید؟ اخه تو پروژه الانتون ShippingMethod رو نول پذیر تعریف کردید و هیچ جایی ازش استفاده نکردید، معلوم نیست چجوری قراره استفاده بشه.
محمد اشرافی
هنوز پیاده سازی نشده ، یه aggregate دیگه اضافه میشه برای لیست روش های ارسال بعد موقع Checkout مشخصات اون روش پرداخت گرفته میشه ، تبدیل میشه به اون ValueObject و بعد به order اختصاص داده میشه
دلیل اینکه nullable ه اینه که موقع ساخت Order نیازی نیست باشه ، فقط زمانی پر میشه که سفارش Checkout شه
محمد اشرافی
“روش پرداخت” نه منظورم همون "روش ارسال" بود