اولین لایه از بیرون نمایش داده یمشه presntation هستش هدفش ارتباط با دنیای بیرون یا همون کاربر هستش
لایه بعدی که لایه بیرونی هستش میشه infostracture مثلا چیزهایی که قراره توی ساختمان سازی داره استفاده میشه
اطلاعاتی که از بیرون رسیده رو میخوایم یه جایی ذخیره کنیم و این باید یه زیر ساخت دیتابیسی داشته باشیم که بتونیم داده ها رو ذخیره کنیم که بهش میگن persistance
مورد بعدی اینه که بتونیم به دیتابیس وصل بشیم و اطلاعات رو توش ذخیره کنیم حالا ممکنه sql باشه postqres باشه یا هر چیز دیگه
تکنولوژی هم که میخوایم باهاش به این ها وصل بشیم میتونه Ef باشه یا ado باشه یا هر چیز دیگه ای
دو مورد داریم نوع وصل شدن به ذخیره ساز خوده ذخیره ساز
توی لایه infostructure هستش ، مثلا میخوایم ایمیل ارسال کنیم باید یه سرویس به اسم smtp داشته باشیم که بیاد به این emial provider ها وصل یشه
خوب یه موقع ها ما میتونیم این سرویس ها رو برای خودمون داشته باشیم مثل sql ولی یه موقعی برای خودمون نیست ولی میخوایم ازش استفاده کنیم مثل gate way پرداخت بانکی
ما دو لایه بیرونی داریم دو لایه درونی
لایه ی presntation جهتش رو به بیرون هستش و برای infostucture هم جهتش رو به بیرون هستش و به معنی این که سرویس هایی که ما میخوایم ازشون استفاده کینم ، فرقشون اینه که توی presntion داریم سرویس میدیم ولی توی info داریم سرویس میگیریم از بیرون
تلفیق application , domain میشه core
در لایه domain دو تا موضوع داریم در مورد چی میخوایم صبحت کنیم ؟ کسب کار بعدش میشه سفارش بعدش میشه اقلام اطلاعاتی سفارش بعدش میشه نحوه ی تحویل بعد میشه روش پرداخت بعد میشه به چه کسی تخویل داده بش و …
خوب ما اطلاعت رو داریم مثلا جنس a و b که چون مثلا دمه تاریخ انقضا هستش تخفیف بهش میخوره
حاالا یه کد منصر به فرد و خاص داریم مثلا برای یک کالا
مجموعه از ویژگی های رو میتونیم بزاریم کنار هم و بهش یه کد خاص بدیم
قواینیی که میتونیم بزاریم به صورت جدا جدا ، مثلا جنس یک تخیف فلان درصد داره یا مثلا فقط فلان قدر درصد تخفیف دارن در صورتی که نزدیک به تاریخ انقضا هستش ، یا مثلا اگر از این جنس 2 تا خرید یه جایزه بهش میدیم ، و به اشخاص خاصی نیست به هر کسی که خرید کنه
مثلا میتونیم یه کوپن هم برای شخصی که خرید هاش زیاد هستش در نظر بگیریم و …
خوب دامین : خصوصیتایی که در کنار هم یه موضوعی رو تعریف میکنن مثلا کالا یا کاربر و … دوم » شناسه ای که باعث تمایز و خاص شدن اون ها میشه که میشه identifere که قابلیت ردیابی داره سوم : قوانینی که جداگونه ای که تعریف میشه
لایه application میاد سناریو ها رو پیاده میکنیم برای فروش » هر کسی که خواست یه کالایی رو بخره اول بیاد سفارشش رو بیاد بده به دامین و بعد محاسبه میکنه چقدر باید پول بده و مالیاتش رو محاسبه میکنه و باید ارسال بشه و … بعد اپلیکشن میاد سبدی که مشتری درست کرده رو میرسونه به دست دامین و یه چورایی واسط هستن برای انتاقل اطلاعات
خوب لایه ی app میاد میخواد اطلاعات رو ذخیره کنه میره اطلاعات رو میده به info و بعد میگه که ای دی و شماره سفارش رو داشته باش و بعد فاز بعدی شروع میشه که میاد یه پیامک ارسال میکنه که این سرویسش توی info هستش اون رو میگره app و بعد اون شماره سفارش رو باهاش میفرسته ، خوب کالا مثلا 3 تا خریدی میره به info میگه که اینا رو رزرو کن و اگر پرداخت بعد از 5 دقیه انجام شده تعداد 3 تا رو از کل اجناس کم میکنه
خوب دستورات از سمت app به دامین و info میره
توی معماری های onion میشد دامین اصلی ترین قسمت ، بعد طی زمان یه سری تکنولوژی جدید اضافه میشد و به مشکل میخورد
اتصال بین لایه ها ایجاد شد یعنی بین app و info کوپل شدگی اینجاد شد و این قضیه به مشکل خورد
توی clean اومده گفته که یه سری قانون گذاشته
مهمترین موضوع در clen میشه framework agnostic میشه یعنی چیزی رو نیای استفاده کنیم که کل سیستم بهش وابسته بشه و دیگه نشه تغییرش شد
49
اگر این قوانین رعایت بشه معماره clean هستش و uncle bob کسی بود که برای اولین بار مطرحش کرد و یه کتاب دیگه است به اسم clean code برای ایشون هستش
نرم افزار طوری توسعه داده بشه که به هیچ چیزی وابسته نباشه
مثلا توی info داریم از اپلیکیشن های دیگه داریم استفاده میکنیم و بیایم براش اینترفیس تعریف کنیم و بعد توی برنامه ازش استفاده کنیم
مورد اول تعریفش این بالاییست
مورد دوم تست پذیر باشه
اولیت با تست کدوم قسمت از نرم افزار باشه
اول باید core رو تست کنیم
مورد سوم : عدم وابستگی به user interface برای همین mvc از بین رفت و web form هم برای همین از بین رفت
مورد 4 : عدم وابستگی به دیتابیس
مورد پنجم : هر چیزی که خارج از لایه برنامه داره استفاده میشه رو نباید بهش وابسته بشیم ، یعنی اگر اون سرویس عوض بشه همه چیز از بین میره که اینطوری درست نیست
کل سرویس ها و مواردی که نیاز داریم روی یک پروژه انجام بشن میشه monolight
و یه سبک دیگه هست که به اسم microservice که زمانی که بخش هایی از پروژه فرکانس فراخوانی زیاد باشه یا منشا تغییرات زیاد باشه میتونیم اون رو بیاریم بیرون و مستقلش کنیم
بهتره که اول پروژه رو به صوت modular monolight ببریم جلو و بعد microservice اش کنیم
وقتی که میخوایم یه چیزی رو توضیح بدیم نگاهمون عمودی هستش
برای پیاده سازی dry
اگر این ها رو رعایت کنیم
اول اینترفیس طراحی میشه و بعد یه کلاس asbtract تعریف بشه و بعد پردازش رو در قالب generic بیاد پیاده سازی کنه و بعد در کلاس concrite که میشن کلاس های اصلی که در نرم افزار حالت عملیاتی دارن رو اضافه میکنیم
اینطوری میشه Ientity - بعد میشه Entity بعد میشه کلاس product مثلا
به جای تمرکز بر این که دیتا چجوری قراره ذخیره بشه بیاد تمرکز بشه بر این که چه کاری قرار است انجام میشه
معمولا توی بحث برنامه نویسی اینطوری نیست که مثلا یه عملیات انجام بشه و بعد بره اطلاعات رو از دیتابیس بخونه بعد دوباره یه کار دیگه بکنه بعد دوباره بریزتش توی دیتا بیس و اینطوری باشه معمولا توی دامین اینطوری که تمام عملیات و flow برنامه داره پیاده سازی میشه و بعد دیتابیس ذخیره میشه
خوب اگر rip رو با ddd ترکیب کنیم میرسیم به repository pattern
خوب اینجا اول اینترفیس تعریف شده بعد پیاده سازی gerneric و بعد کلاس ولی چون domian هم بهتره که قراردا هاش uniqe باشه برای همین هم اومده و یه اینترفیس هم سمت domian پیاده سازی شده
خوب eshop api میشه host ما که منطق کل برنامه میاد روش پیاده سازی میشه
خوب توی framework الزامات طراحی و معماری و قراداد ها رو اینجا میزاریم
مورد بعد
تقریبا جلسه 7 تا اینجاهاست
خوب اینجا یه اینترفیس specific داریم که داره از یه ریپازیتوری genric داره ارث بری میکنه ولی وقتی که داره بینشون segrigation اتفاق میوفته
وقتی که segrigation داره بین دو تا اینترفیس اتفاق میوفته specification هم داره انجام میشه این یعنی این که سمت چپ اصلا نباید generic باشه و سمت راست specify میشه به تایپ هایی که مشخصه هستش دیگه TEntity و از این قبیل نمیتونه باشه
خوب اینجا لایه present میاد درخواست رو از بیرون میگیره و با یه dto میفرسته سمت app و app میاد با domain ارتباط میگیره و میپرسه که آیا این شخص میتونه خرید کنه ، هزینه اش چقدره ؟ تخفیف داره و … ؛ حالا دامین میاد میگه که حالا که همه چی اوکیه این درخواست رو ثبت کن این رو domain به application میگه و app میره با info ارتباط برقرار میکنه و درخواست رو میفرسته برای info بعد info هم اون رو ثبت میکنه و بعد از این که ثبت کرد info یه پاسخ رو میفرسته به app و app هم اونو میفرسته به presentiation
حالا میرسیم که ارسال پیامک ، اینترفیس ارسال پیامک توی لایه app هستش ولی پیاده سازیش توی info
خوب app جریان کاری رو داره تنظیم میکنه و میاد از این اینترفس استفاده میکنه ولی پیاده سازی در info انحام میشه
و presntation هم منتظر هستش که این کار ها در لایه های پایین تر انجام بشه بعد نتیجه رو میگیره و بعد نمایش میده
نکته : در لایه presnt ما بایسیتی بیایم یه سری validation هایی که خیلی تابلو هستش رو چک میکنیم که بار چک کردن های ابتدایی رو نفرستیم سمت سرور
هر چیزی از نوع جریان کار باشه میشه app و هر چیزی که مربوط به busines logic هستش رو توی دامین مینویسیم
هر چیزی که از جنس تکنولوژی هستش میره توی info
هر جیزی که از نوع ارتباط هستش مثل این که یه سرویسی میخواید یه سرویس دیگه رو صدا بزنه میره توی app
مثلا میتونه یه اپلیکشن blazor باشه میتونه angular باشه یا هر چیزی
و در presntion هم مدل های مختلف پیاده سازی داریم
حالا بعد از soap اومدن rest , grpc , web socket جایگزین شدن و اینها توی لایه presntion پیاده سازی میشن
خوب لایه presnt باید بیاد و یه قرارداد تعریف کنه که لایه app بیاد اون رو درست کنه که متونیم برای سادگی اول قرارداد ها رو توی لایه app پیاده سازی کنیم و بعد ببریم سمت presntion یا بیایم قرارداد ها رو توی لایه presnt تعریف کنیم و توی لایه app پیاده سازیشون کنیم
خوب توی قواینین clean داره میگه که اول پروژه prent و info رو بیخیال شو
بعضی میان توی لایه app قرارداد ها رو تعریف میکنن و بعد رفرنس میدن به presnt
بعضی میان توی prenst میان قرارداد ها رو تعریف میکنن و بعد prenstion رو به app میان و رفرنس میدن ، این مدل کاملا غلط هستش چون که لایه prenst نباید به لایه app رفرنس داده بشه
میتونیم لایه prenst رو به لایه app رفرنس بدیم
خوب اگر در pre بیایم و قرارداد هارو تعریف کنیم و بعد بخوایم توی app پیاده سازی کنیم باید بیایم بریم توی app و بزنیم رفرنس به pre
خوب حالا به خاطر این که این داستان ها به وجود اومده برای این که بخوایم لایه ی pre رو مستفل کنیم میام یه کلاس دیگه به اسم …
خوب اگر core اولیت هستش باید اول core نوشته بشه و توش قرارداد ها تنظیم و بعد توی لایه های دیگه پیاده سازی انجام بشه
خوب اینجا توی نام گذاری هم باید دقت کنیم اینجا ما همچنان نوشتیم application و بعد contract دلیلش اینه که اپلیکیشن همچنان اولیوت application و domin اولیتش بالاتر از presentation هستش
اینترفیس های نظارتی و مدیریتی sufiix که دارن manager هستش
خوب بهترین حالت برای اینترفیس ها اینه که ورودی و خروحی هر دو رو dto بگیرن
بهترین پیام ، پیامی هستش که تغییری نکنه برای همین از record استفاده میکنیم که غیر قابل تغییر هستش
بعد اینشکلی میشه
با این کتابخونه میتونیم dummy obj بسازیم :
خوب اینجا چون ممکنه که یجایی به صورت تصادفی اسم این آبجکتمون تغییر کنه و یهو همه چیز بهم بریزه برای همین میایم setter اش رو private میکنیم
خوب مثلا یه نفر میخواد اسمش رو تغییر بده باید بره ثبت احوال و کلی داستان دیگه
مورد بعدی اینه که اون فرد کلی مدارک داره ، گواهی نامه و … که این ها همه باید تغییر کنند
خوب حالا به هر دلیلی تعییرش دادیم بعدش میتونیم همه رو مطلع کنیم که این تغییر انجام شده و این اسم جدیده
همینطور قیمت
خوب
اینجا نکته ای که داره اینه که ما اینجا وقتی که میخوایم یه product رو بسازیم باید تمام مشخصاتی که لازم هستش رو براش وارد کنیم
ولی یه موردی که هست مثلا ی چیزی مثل descriptin اگر لحظه ی تولید محصول هم نزدیم چون setter داره بعدا میتونیم بهش اضافه کنیم
اگر بهش مقدار ندیم که میشه empty اگر بدیم که تغییر میکنه
خوب
به جای dto مینویسیم request
خوب برای دسترسی به end point
خوب اول اومدیم IEndpoint رو درست کردیم
و بعد اومدیم توی endpoint extention کاری کردیم که کل endpoint ها رو بیاد اتوماتیک رجیستر کنه
بعد هم توی middle ware اومدیم ازش استفاده کردیم توی app . map profile
1:49
این جا سرویس ها رو extend میکنیم و توی middleware extention هم middle ware ها رو اکستند میکننیم
یه IEnd point داریم که اینترفیسش قراره توی تمام pres ها ازش استفاده کنیم
خوب ما یه عالمه ماژول داریم که همشون باید از این اینترفیس استفاده کنند :
خوب حالا برای استفاده این ماژول ها از این اینترفیس میایم یه کلاس lib درست میکنیم
بعدش این اینترفییس رو میبریم اون تو
خوب این class lib به هیچی دسترسی نداره ، یعنی دسترسی به اینترفیس های asp . net نداره خوب core یه چیزه و asp .net یه چیزه دیگه است
خوب به همین دلیل ما اینجا ارور داریم برای استفاده از Iendpoint route builder چون که دسترسی نداره به همچین اینترفیسی
این اینترفیس از جنس asp .net core هستش
خوب بعضی ها در این شرایط میاین این لایه framework presention رو از جنس api تعریف میکنند که مناسب نیست
یه endpoint ex داریم که میاد end point ها رو رجیستر میکنه این رو هم میبریم توی framework pres
بعد هم میایم رفرنسش رو درست میکنیم :
خوب pre میتونه به خودش رفرنس داشته باشه
خوب اینجا task delay میشه نماینده call کردن لایه app
پروسه ltp یعنی چی ؟
کپی میکنیم این ور pasete میکنیم :
بازبینی و پیاده سازی این جلسه از ابتدا انجام شود