عرض ادب و خسته نباشید.
استاد شما توی یکی از ویدئو ها گفتین
به جای اینکه به ازای هر Entity یه اپ داشته باشیم، مدل های مرتبط با یک موجودیت اصلی و سرد دسته را در کنار هم در یک اپ قرار میدهیم. Aggregate Root.
اما تو پروژه شما برای هر صفحه دارین یه اپ میسازین که تا جایی که میدونم خیلی استاندارد نیست مگر اینکه سیستم مدیریتش تخصصی باشه
contact_module
home_module
این دوتا میتونستن کنار هم باشن. دلیلی داره این ساختار؟
سلام خدمت شما دوست عزیز
ببینین مبحث ماژولاریتی به این اشاره میکنه که شما بتونین یک ماژول رو به راحتی با کپی کردن توی یک پروژه ی جدید استفاده کنین
حالا سوالی که مطرح میشه اینه که اگر contact us در کنار home باشه میتونین به راحتی این کار رو انجام بدین یا خیر
موضوع اینه که اگر رویکرد domain driven design رو در نظر بگیرین ( چون شما از واژه ی aggregate root استفاده کردین این مورد رو عرض میکنم ) ماژول تماس با ما خودش یا یک domain در نظر گرفته میشه یا sub-domain ماژول contact
پس عملا بهتره که این ماژول رو جداگانه در نظر بگیرید. البته از اونجایی که پروژه ی ما فقط یک مدل داره و کارایی سنگینی رو نمیشه براش در نظر گرفت معمولا برای راحتی کار اون رو توی app مربوط به home یا همون base پیاده سازی میکنن اما بهتره که جداگانه باشه
البته این هم در نظر داشته باشین که من در دوره به ازای هر صفحه یک app ایجاد نکردم
ماژول تماس با ما جزو مواردی هست که از نظر رویکرد ddd باید جداگانه در نظر گرفته بشه اما چون توی پروژه ی ما صرفا یک view داره ممکنه افکار به این سمت بره که پس میشه اون رو در داخل یک ماژول دیگه پیاده سازی کرد که این مورد اشتباه هستش
تا جایی که امکان داره سعی کنین پروژه رو طوری پیاده سازی کنین که در پروژه های بعدی با انتقال app جنگو و تعریفش در installed_apps بشه راحت ازش استفاده کرد
موفق باشین :)
Chat GPT میگه:
اشتباه رایج: «هر صفحه = یک اپ»
این اشتباه از اینجا میاد که بعضیها فکر میکنن وقتی میگیم «بر اساس دامنه» یعنی:
home about contact faq
این دیگه Domain-based نیست، این «Page-based» یا «UI-based» هست، و تو جنگو تقریباً همیشه کار اشتباهیه، چون باعث انفجار اپهای بیمصرف میشه.
دامین بیس یعنی:
هر اپ یا ماژول بر اساس یک بخش منطقی از سیستم یا کسبوکار ساخته بشه.
accounts: Login, Register, Profile
products: product list, catalog
orders
blog
pages: Contatc-Us, Home, AboutUs
اما طبق صحبتتون منظورتون رو متوجه شدم. حرف شما درسته . باید مرزبندی از ابتدای پروژه انجام بشه.ضمن اینکه ممکنه سیستم مدیریت هم بزرگتر باشه
خیلی ممنون بابت پاسخ و وقت گذاری. جسارتا سوال دیگه اینکه
این ddd خیلی موارد و پارامتر های پیچیده و بزرگتر دیگه ای داره که نمیدونم تو سیستم ها یا وب سایت هایی که عموما مینویسیم کاربرد داره یا نه
مثل Entities + Aggregate Root - Value Object - Bounded context ,..
مثلا چیزی که من میدونم سیستمی که ما استفاده میکنیم بیشتر یه مقیاس کوچیکی از ddd هست به اسم Feature Base یا ddd کلاسیک
ببینین توی دوره بنده از ddd استفاده نکردم دوست من. برای استفاده از این رویکرد ، مباحث مهمی مثل repository و سرویس ها و value object ها و همینطور aggrigate root ها رو باید بررسی کنیم. مباحث domain باید کامل تفهیم بشن و در یک پروژه قابلیت تشخیص این موارد رو داشته باشیم که از مباحث این دوره کاملا جدا هستش
بنده صرفا با استفاده از app های مختلف سعی بر این داشتم که دانشجویان دوره بتونن در آینده bounded context ها و domain ها و sub domain ها رو تشخیص بدن
در کل کدی که در دوره نوشته شده صرفا آموزش مباحث جنگو هستش و هیچ رویکرد و یا معماری خاصی رو پیاده سازی نکردیم. البته که خود جنگو از mvt استفاده میکنه اما ما کدی رو مبنی بر پیاده سازی اصول خاصی پیاده سازی نکردیم
البته در نظر داشته باشین که این دوره ، آموزش فریم ورک جنگو هستش و نه آموزش Domain Driven Design و مباحث باید کاملا ساده و کاربردی برای دانشجو تدریس بشن
باز هم خیلی خوشحالم که توی این مسیر به صورت خودجوش سعی در عمیق شدن مباحث و یادگیری فراتر از مباحث دوره رو دارین
موفق باشین :)
مخصوص اعضای ویژه 
