تفکیک پروژه ها در معماری تمیز

[mmbguide]

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

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

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

155456

[fakhravari]

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


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

https://github.com/fakhravari/Clean-Architecture

[mmbguide]

سلام جناب fakhravari. ممنون بابت توضیحاتتان.

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

[mmbguide]

سلام

جناب فخرآوری یک سوال. آنچه که متوجه شدم با پیاده سازی MediatR میشه منطق برنامه را در Handler پیاده سازی کرد. آیا در در چنین شرایطی پیاده سازی لایه Service ضروریه؟ اگر ضروری نباشه ایا پیشنهاد میشه که پیاده سازی بشه یا پیاده سازی Business برنامه در Handler کفایت میکنه؟ تشکر

[fakhravari]

سلام

جناب فخرآوری یک سوال. آنچه که متوجه شدم با پیاده سازی MediatR میشه منطق برنامه را در Handler پیاده سازی کرد. آیا در در چنین شرایطی پیاده سازی لایه Service ضروریه؟ اگر ضروری نباشه ایا پیشنهاد میشه که پیاده سازی بشه یا پیاده سازی Business برنامه در Handler کفایت میکنه؟ تشکر

در این معماری MediatoR که واسطه بین request و response است میشه از FluentValidation برای منطق بیزینس استفاه کرد و به نظرم استفاده از این معماری کفایت میکنه.

[mmbguide]

سلام مجدد

با توجه به مرور نمونه موجود در repo و نگاه به سایر نمونه ها آنچه که متوجه شدم نامگذاری پروژه ها با نام Entities, Models و Dtos بوده:

مثلا در Domain یک Entities تعریف شده و یک Model. آیا در اینجا Model همان Dto هستش؟
در برخی نمونه ها دیدم که عین Entities در Persistence جهت ایجاد DbContext استفاده شده. آیا نمیشه از همان Entities موجود در Domain برای DbContext استفاده کرد. در توضیحات آمده بود که کلاس های Domain بدون Attribute و کلاس های مشابه در Persistence دارای Attribute هستند.
تا چقدر ضروریه که به غیر از Entities و Dtos در Domain در جاهای دیگه Model تعریف کنیم؟


تشکر

[mmbguide]

سلام

در ادامه پست شماره #6 یک سوال دیگه به ذهنم رسید که در طراحی DDD آیا همین تفکیک پذیری درسته؟

[fakhravari]

سلام مجدد

با توجه به مرور نمونه موجود در repo و نگاه به سایر نمونه ها آنچه که متوجه شدم نامگذاری پروژه ها با نام Entities, Models و Dtos بوده:

مثلا در Domain یک Entities تعریف شده و یک Model. آیا در اینجا Model همان Dto هستش؟
در برخی نمونه ها دیدم که عین Entities در Persistence جهت ایجاد DbContext استفاده شده. آیا نمیشه از همان Entities موجود در Domain برای DbContext استفاده کرد. در توضیحات آمده بود که کلاس های Domain بدون Attribute و کلاس های مشابه در Persistence دارای Attribute هستند.
تا چقدر ضروریه که به غیر از Entities و Dtos در Domain در جاهای دیگه Model تعریف کنیم؟


تشکر



ویو مدل های در سطح ریپازیتوری در لایه Application باشد و سایر در لایه Domain. حال فرقی نداره اسم گذاریش
من دیتابیس فرست میرم جلو با Note.txt که گزاشتم دیتابیس جنریت میکنم و مدل میسازم و هر لایه درون فولدر های خودش میزارم


بحث DDD فرق داره و اصولی پیاده سازی کردنش خیلی لایه مختلف داره که در ساختار کلین نیست. کلین یک الگوی تمیز توی سلوشن های بیزینسی کوچک هست که ساختار کد منظم میکنه

https://virgool.io/@farshid.azizi/implementing-ddd-clean-architecture-tcixfzbtkqkz

[mmbguide]

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

در پروژه از MediatR استفاده کردم. در پیاده سازی کلاس هایی که باید از IRequest ارث بری کنند و برای عملیات اصلی مانند Create برای ساده سازی نامگذاری کلاس بصورت CreateCommand و CreateCommandHandler هستش. تمام این کلاس ها در پوشه های مربوط به خود هستند و namespaceها کاملا جداگانه هستند. تا اینجای کار اگر 100 تا domain داشته باشم برای تمام آنها 100 تا CreateCommand و CreateCommandHandler دارم. اگر برنامه را بدون Swager اجرا کنم هیچ مشکلی نیست و تمام Apiها کار میکنه ولی اگر Swagger را برای مستندسازی فعال کنم با خطا مواجه میشم و در Console خطایی که نشون میده به این مفهوم هستش که از Schema تکراری استفاده شده و نام آن را هم CreateCommand اعلام میکنه.

آنچه که متوجه شدم کدهای APi ایرادی ندارند ولیSwagger نمیتونه کلاس های همنام رو مدیریت کنه. سوالم اینه که اگر این موضوع صحیح باشه آیا راه حلی هم وجود داره؟

تشکر

[mmbguide]

متن پیغام:

Failed to generate schema for type:
Ces.Caspian.Application.Commands.User.UserProfileD etails.CreateCommand


The same schemaId is already used for type:
Ces.Caspian.Application.Commands.User.UserProfiles .CreateCommand

[mmbguide]

جهت رفع مشکل باید تنظیم زیر را در Swagger فعال کنید:


builder.Services.AddSwaggerGen(config =>
{
config.CustomSchemaIds(x => x.FullName);
});


در واقع بصورت پیشفرض Swagger فقط نام کلاس را بررسی خواهد کرد که با تنظیم فوق Swagger از نام کامل که همان namespace است استفاده خواهد کرد. در این شرایط نام کلاس ها در مستندات بصورت FullName نمایش داده خواهد شد.