یادتون باشه وقتی میگیم معماری داریم از بنیان یک نرم افزار صحبت‌ میکنیم، در اصل بنیان یک نرم افزار بر پایه دیزاین پترن ها و لایه ها نیست بلکه ساز و کار ارتباطات و عملکرد کلی یک نرم افزار رو شرح میده.

خیلی وقتا میشنویم میگن معماری MVC و MVVM و DDD و Cqrs.. کلا هر چی پترن و رویکرده رو میریزن تو معماری. درباره همه اینا قبلا مفصل نوشتم:
معماری، معماری طراحی، الگوی طراحی.
صرفا چندتا مفهوم غلط اندازه مرسوم رو میگم بازم:

معماری های: سرویس گرا، مبتنی بر سرویس و مایکروسرویس، معماری مونولیت یا همون یکپارچه، MainFrame و ..

معماری های طراحی: MVC, MVVM, MVP
الگوی های طراحی: UnitOfWork، الگوی تزریق وابستگی، الگوی استراتژی، الگوی سینگلتون، الگوی ریپازیتوری، الگوی request reaponse،
* الگوی طراحی معماری (گاها به عنوان رویکرد طراحی هم شناخته میشه) کامند کوئری CQRS (اشاره داره به جدا کردن store و مسئولیت مدل دستورات یا کامندها از کوئری ها ) و event sourcing pattern

متدلوژی و رویکرد ها / تفکر ها مثل،
توسعه دامین محور DDD (طراحی برپایه بیزنس دامین های نرم افزار)،
توسعه تست محور TDD (توسعه بر پایه تست های واحد از پیش نوشته شده، برعکس توسعه معمول که اول پیاده سازی انفاق میفته بعد تست های نفس گیر)،
رویداد محور EDD ( event driven )،
رویکرد پر استفاده رفتار محور BDD ( بزن در رو حالا خدا بزرگه ببینیم چی میشه محور)، رویکرد CDD کپی محور، فحش محور FDD (سازمان ِغذا و دارو امریکا) و ...

یادتون باشه که مثلا شما مجبور نیستید طراحی CQRS پیاده کنید، میتونید همونا رو در یک سرویس بنویسید و همه عملیات crud رو داخل خودش پیاده کنید، اما اگر نیاز دارید به:
- افزایش خوانایی، تفکیک وظایف مدل ها و حذف وابستگی های اضافی.
- جدا کردن عملیات هایی که تغییری در وضعیت و داده های سیستم میدن و خروجی ندارن
- جدا کردن عملیات هایی که تغییری نمیدن و صرفا کوئری های read هستن و خروجی میدن
- صدور دنباله ای از event ها، که بقیه سرویس ها رو از تغییری مطلع میکنن یا میگن بعدش کار دیگه ای رو انجام بده (داخل سیستم یا سرویس های خارجی). مثلا اپدیت کردن کش، دیتابیس read، اپدیت رکورد تو سرویس دیگه ای، زمان بندی انجام کاری در پشت صحنه و صف پیام
- جدا کردن storage داده ها، مثلا جدا کردن دیتابیس read از write برای افزایش پرفورمنس، مقیاس پذیری و parallelism و امنیت
- نگهداری تاریخچه تغییرات دیتا ها و رویداد های نرم افزار به منظور، لاگینگ، گزارش گیری، بازگردانی و رهگیری اتفاقات.
بهترین معماری و الگوی طراحی ای که پیدا میکنید همین CQRS و Event Sourcing عه که به وفور در میکروسرویس ها، سیستم های مقیاس پذیر، سرویس هایی با کوئری های بزرگ و پیچیده استفاده میشه.
به همین خاطر اگر دیدید یک سرویس داره روز به روز بزرگتر و پیچیده تر میشه، وابستگی های زیادی رو تزریق میکنه که لازم نیست بخاطر صدا زدن یک تابع کوچیک استفاده بشن، بهتره معماری رو یک بازنگری بکنید و مسئولیت های سرویستون رو به کامند و کوئری های مستقل بشکنید.
ولی اگر یکی دوتا کلاس سرویس و ریپازیتوری کوچیک دارید که نهایت شیش هفت تا متد و عملیات داره و روز به روز بزرگتر نمیشه و لازم نیست دیتابیس خوندن رو از نوشتن تفکیک کنید، cqrs بیشتر کارتون رو پیچیده و توسعه تون رو زمان بر میکنه. ضمن اینکه برنامه نویس های کمی هستن که واقعا درک و تجربه ای ازش داشته باشن تا سر از کد ها و ساختار در بیارن.
#Architecture #DesignPattern #ArchitecturalPattern #Approach
@csharpfriends