قطعن تو محیط کار یا مصاحبه یا ... اسم معماریهای DDD یا CQRS یا Microservice رو زیاد شنیدید. کلن شدن trend این روز

اما این معماریها اینقدرها خوب هستن؟

آیا  معماری سه لایه تو حوضه clean code  دیگه جایی نداره و یا زیادی ابتدایی و پیش پا افتادست؟

خیلی از ماها اولین معماری که در حوضه clean code آشنا میشیم معماری سه لایه ست. بعد یواش یواش یا اسمهای به ظاهر قشنگتر و حرفه ای تر روبرو میشیم مثل CQRS یا DDD یا در سطح معماری کل سیستم  microservice .

همه این معماریها در کنار خوبیهایی که دارن ، مشکلاتی هم با خودشون میارن که میخوام به برخی از این موارد اشاره کنم

بدیهای DDD:

تشخیص درست aggregateها بیشتر وقتها به همین آسانی که فکر میکنید نیست. همین الان تو بازار پر از کدهای به ظاهر خشگل که همه قواعد رو رعایت کرده وجود داره در حالی به خاطر تشخیص نادرست مرزها و aggregateها کد، نه تنها پرفرمنس به شدت پایینتر از چیزی که میشد داره ، حجم زیادی از کدها نیاز با بازنویسی و بازبینی داره . کدهایی که بخاطر اشتباه در تحلیل و شناخت سیستم نوشته شدند

مورد بعدی ،لود دیتا هست. از اونجایی که میدونیم یه aggregate با همه relationهاش لود میشه، هر شرکتی (تازه نه همشون) بعد از یه مدت که دیتابیسشون بزرگ میشه مشکل رو میفهمنن، در حالی زمان توسعه همه چی خوب بود. تازه اینجاست که میان میشینن برا مشکلی که خودشون به وجود آوردن میخان solution پیدا کنن که خدا میدونه تهش چی از کار در میاد(البته بعضیاشون هم solutionهای درست و خوبی پیدا میکنن)

بدیهای CQRS:

دیباگ کردن و trace کردنش فقط برا کسی که کد و  نوشته آسونه 😂

وای از اون روزی که داخل یه هندلر یه هندلر دیگه هم کال بشه و ...  یادت میره اولش کجا بودی😂

ایراد دوم که زیاد دیدم . یه برنامه نویسی یه هندلری نوشته (فرقی نداره command یا query)  و حالا از تیم جدا شده . به برنامه نویس بعدی که داره تو پروژه کار میکنه بیزینسی شبیه همون قبلی بهش بگی با ظریب ۹۰ درصد قول میدم میره از اول مینویسه. چون هم نمیتونه هندلر رو پیدا کنه که بخاد تغییرش بده(اصن نمیدونه هست یا نه) هم اینکه اگرم پیدا کنه چون نمیدونه کجاها ازش استفاده شده ترجیح میده یدونه جدید ایجاد کنه که خیال خودشم راحت باشه

بدیهای Microservice:

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

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

قطعن که کنار این مشکلات (که نظر من بود البته) کلی هم خوبی دارن که خودتون میدونید دیگه تکرار نمیکنم. ولی من خودم برای شروع پروژه (اگر نسخه ۱ باشه نه جنس بازنویسی پروژه قبلی یا ... ) اصن توصیه نمیکنم چون حجم زیادی کد و بازنویسی در حین توسعه رو بهتون تحمیل میکنه.

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

نتیجه گیری: (نظر شخصی)
به جرات میگم یه معماری زمانی ارزشمنده که به شما کمک کنه بیشتر درگیر بیزینس بشی که کار مشتری و تحویل بدی نه اینکه اینقدر با خودش نکته و پیچیدگی فنی داشته باشه که نیازمندیهای مشتری بره ته صف😂

همه اون معماریها خوبن ولی نه اینکه پروژت رو با اونا شروع کنی. هر چی بیشتر جلو بری بیشتر درگیر پیچیدگیهای فنی میشه تا خود بیزینس و به دلیل شناخت ناکافی از کل فضای صورت مسله حتمن بارها و بارها مجبور به refactor  میشی . اما اگر پروژه ای رو شروع کردی که کامل اشراف داری به بیزنیسش (یا تا حد خیلی خوبی) میتونه انتخاب درستی باشه .