این روش درسته بنظر شما؟

درستم میگید، متود AddSub یکم بی فایده بنظر میرسه، پس یعنی اون پراپرتیه Childs که داخل Category هست هم بی فایده میشه دیگه؟ خب، پس چیکار کنم، اگر اون متود AddSub و لسیت Childs رو حذف کنم پس ینی هیچ رابطه ای نزارم بینشون؟ آخر سر میتونیم بریم Query بزنیم چایلد هاشونو بیاریم؟ اینجوری پس اصلا ساختن اگریگیت و این چیزا چه فایده ای داره، متوجه نمیشم واقعا 🤔

مگه کلاس کتگوریه من نباید یجورایی نمایانگر Domain و بیزینس رول های من باشه، که مثلا نشون بده که یه ربطی با چایلد هاش داره، مثلا یه لیست از چایلد میتونه داشته باشه. وگرنه ما که میتونیم هیچ رابطه ای نزاریم، اخرش بریم از طریق آیدی هاشون کوئری SQL بزنیم بیاریمشون…

می تونید بزاریدش حذش هم نکنید صرفا برای Relation بر قرار کردن یا اینکه بردارینش و توی تنظیمات Ef رابطه رو ایجاد کنید و توی Query هم مشکلی برای دریافت ندارید

توی این حالتی که شما الان دارید کار میکنید اون Entity تبدیل شده به یه Anemic Domain Model اگر واقعا روی این موارد خیلی حساس هستید و می خواید همه چی با قاعده پیش بره ، بهتره id رو از نوع Guid بگیرید و توی برنامه بسازیدش

ببینید الان شما روش های مختلف رو می دونید ، پس اگر فکر میکنید سیستمتون داره به جاهای بدی میرسه پس تغییر توش ایجاد کنید ، که اون جوری بشه که باید بشه 

استفاده از Guid هم ترسی نداره ، اتفاقا توی Rich Model ها بهترین روش ه 

اون انتیتی چرا تبدیل شده به یه Anemic Domain Model؟ بعد آیدیشو Guid کنم چجوری باعث میشه که Rich Model محسوب بشه؟

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

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

خب این کتگوریه من یه سری Behavior داره داخل خودش، خالیه خالی هم نیست.

بعد الان منظورتون کدوم منطقه که داره خارج از انتیتی انجام میشه؟ همین سِت کردن آیدیش؟ یا اون سِت کردن specification هاش (اونجا که foreach زدم روش).

خوب اگر منطق داره که بهتر 

منظورم اضافه کردن Child ه ، وقتی یک Category میسازید ، یعنی این Category ه - ولی شما می خواید ChildCategory بسازید پس دیگه توی ادبیات دامنه شما new Category به این معناست که قراره یه Parent بسازید و برای AddChild نباید بگید یه Category بده ( باز هم میگم همه جا استثناء وجود داره و ممکنه یه جا مجبور باشیم که این کار رو انجام بدیم ، ولی اگر این کارا زیاد بشه خیلی خوش آیند نیست )

آها، درسته این کار زیاد جالب بنظر نمیاد، البته تو سیستم من زیاد پیش نیومد، همینجا بود فک کنم فقط، حالا معلوم نیست باز شاید پیش اومد، بعد استاد این بحث مربوط به کدوم مبحث از DDD میشه؟ اصن جزوی از best practice های DDD بود این چیزی که گفتید؟ اگر آره لطفا اسم اون مبحث رو بگید اگر شد یکم بیشتر تحقیق کنم، (احیانا مربوط به Ubiquitous Language نیست؟ 🤔) و اگر مربوط به DDD نیست، اسم این best practice چی بود کلا، ممنون.

بعد استاد یه چنتا سوال ریز هم داشتم، همینجا بپرسم جمع شه دیگه، زیاد مربوط به این سوال نیست ببخشید 😂

استاد، من داشتم این Query هارو پیاده سازی داریم، بعد سوال شد برام که این لایه Query کلا مربوط به لایه Application میشه؟ یعنی جزوی از Application به حساب میاد یا نه؟ آخه Command هامون رو توی Application نوشته بودیم، فک کردم کوئری ها هم مربوط به همون چیزا میشه کلا، ینی نوشتن و خوندن اطلاعات از دیتابیس، اینطوری نیستش نه؟ لایه کوئری یعنی حتی از لایه Infrastructure هم بیرونی تره؟ 🤔

بعد اینکه الان شما توی پروژه همین Web API، داخل لایه Infrastructure گرفتید DapperContext رو ساختید، و فقط داخل Inventory یجا ازش استفاده کردید فقط بخاطر تست بود فک کنم و آموزش دَپِر، بعد هیج جا دیگه استفاده نکردید، بعد الان امکانش هست من تو پروژه خودم این DapperContext رو ببرم داخل لایه Query؟ یا نه حتما باید داخل لایه Infrastructure باشه، و بعد توی لایه Query رفرنسش بدم، چون مثلا اصول Clean Architecture اینو میگه.

به UL ربط داره به منطق برنامه نویسی شئ گرا هم ربط داره ، اسم خاصی الان تو ذهنم دقیق نمی دونم اسمش چی بوده ، البته توی فصل های بعدی درمورد UL , Bounded Context و SubDomain که صحبت کنیم ین موارد رو بهتر درک میکنید

نه ببینید لایه Domain و Application توی Core قرار دارن که منطق برنامه رو پیاده سازی میکنن و لایه Query  و Infrastrucure کلا میره بیرون و یه جور تکمیل کننده محصوب میشن

لایه Query صرفا برای نمایش اطلاعات به Client ه و هیچ وابستگی به Domain نداره ( که اگر بخواید کلا از Dapper براش استفاده کنید احتیاجی نیست اصلا از لایه های پایینی Refrence بگیره ( چون اطلا نیاز به مدل ها نداره فقط با Dto کار میکنه ))

لایه Query می تونه برا خودش یه Infras جدا داشته باشه ولی برای اینکه خیلی شلوغ نکنیم از همون استفاده میکنیم چون خیلی مشکلی پیش نمیاد که از اون استفاده کنه ( مگر اینکه بخوایم به مدل های Domain دسترسی نداشته باشه )

** لایه Query رو میتونید بیرونی ترین لایه در نظر بگیرید

خیلی ممنون استاد.