چرا جنگو فریمورک محبوبی هست؟؟؟
بیاید یکم راجبش حرف بزنیم
جنگو خیلی از موارد برنامه نویسی مدرن رو براتون فراهم میکنه بدون اینکه خودتون راجبش حتی دانش کافی داشته باشید و بدونید، که میتونیم به design patterns و clean architecture اشاره کرد
بارها به بچهها گوشزد کردم که business logic رو فراموش نکنید و جدی بگیرید ،کار سختی نیست یک فایل با نام services.py بسازید و موارد مربوط به orm رو داخلش بنویسید (یک دایرکتوری با نام services بسازید و ماژولهای پایتونی خودتون رو داخلش بزارید) حالا کافیه با dependency inversion principle رو بدونید و داخل کدهاتون رعایت کنید
خب چه اتفاقی افتاد؟؟؟
الان شما اومدین و app رو به سه لایه تقسیم کردید لایه application ، لایه service ، لایه infrastructure , خب این چه مزیتی داره برامون
بیایم ببینیم هر لایه شامل چه چیزی میشه؟؟؟
Application: urls, views
درخواستهای مشتری در این قسمت مورد پردازش قرار میگیره که دادههای مورد نیاز رو از لایه service میگیره و اون رو تبدیل میکنه به مقداری که قابل خوندن واسه مشتری هست که میتونه http, drf, grpc و … باشه
Service:
این لایه همون مبحث business logic رو ارائه میده و تمام موارد مورد نیاز رو در خودش هندل میکنه(وظیفه ذخیره و بازیابی موجودیتهارو برامون هندل میکنه) اینجا orm django کار میکنه لایه انتزاع از دیتابیس رو میسازه و بواسطه شی گرایی مارو از پیچیدگی کار رها میکنه
Infrastructure: migrations , models
تو این قسمت شما موجودیتها و مجموعهها رو در یک سیستم ذخیره ساز، ذخیره میکنید ،اینکار با استفاده از مدلهای جنگو و queries صورت میگیره ، بخش مایگریشنها هم اینجا صورت میگیره
من این همه سردرد رو واسه چی دارم تحمل میکنم خدایی؟؟؟
شما دارید ذره ذره به سمت bounded context ها میرید
خب اینکه گفتیم به چه معناست اصلا؟؟
نکته: ما همیشه میگیم تسک بزرگ رو به چند تسک کوچیکتر بشکنید (بصورت منطقی البته) یک کلاس بزرگ ننویسید یک تابع طولانی نسازید
ما اینهارو رعایت کردیم به کجا داریم میرسیم؟؟؟
جالبه بدونید که داریم به سبک معماری DDD نزدیک میشیم
بیایید ادامه بدیم
خب اصل SoC میاد وسط(پروژه میتونه به بخشهای کوچکتر و قابل مدیریت تر تقسیم بشه، اجزا میتونه میکروسرویس یا ماژولهای مستقل در یک مونولیت باشند)
همین ترکیب بالا رو بزاریم داخل microservice ، پروژه خودمون رو به چند سرویس منطقی و درست تقسیم کنیم، مدلهای هر سرویس رو داخل یک دیتابیس جدا بزاریم ، FKهای مدل رو به Bigint تبدیل کنیم ارتباط بین سرویسها رو مدیریت و هندل کنیم (اینجا rabbitmq سلام میرسونه) الزامات سرویسهای بیس رو انجام بدیم (این شد bounded context)
چه اتفاقی داره میافته ؟؟؟
هر بخش داره بصورت مستقل توسعه داده میشه
نگرانی حاصل از پیچیدگی داره رفع میشه
بهبود توسعه کد و پایداری داره بخوبی اتفاق میافته
پایگاه داده از شکستن داره خارج میشه
به معماری DDD خوش آمدید
این معماری برای پروژههای بزرگ مناسبه و اگر یک پروژه قدیمی با حداقل 20 app دارید لازم نیست تعطیلش کنید فقط کافیه با DDD تبدیلش کنید
یک معماری میکروسرویس پیاده سازی کنید
که شامل چند سرویس میشه
هر سرویس در دل خودش چندتا app داره
هر app طبق DDD به سه لایه application , services , infrastructure تقسیم میشه و دیتابیس خودش رو داره
خود جنگو براتون clean architecture رو تا سطح بالایی براتون اتخاذ میکنه
در کدهاتون dependency inversion principle رو رعایت کنید
@code_crafters