https://virgool.io/feed/@mr_rahimi fa 2026-06-16 07:09:17 https://files.virgool.io/upload/users/90107/avatar/RmWwWY.jpeg?height=120&width=120 https://virgool.io/@mr_rahimi https://virgool.io/@mr_rahimi/ddd-in-simple-words-vsfkn71k4zq1 یک برنامه بر مبنای CRUD خیلی چیزی فراتر از ذخیره و بازیابی اطلاعات ندارد. در این جور برنامه ها معمولا مدل های داخل برنامه ما تنها به عنوان یک ظرف برای انتقال اطلاعات عمل میکنند(Data Transfer Object).اماشرایطی را در نظر بگیرید که یک عملیات در برنامه(مثل سفارش یک محصول) بر روی وضعیت بخش زیادی از سیستم تاثیر می گذارد(مثلا بر روی سیستم انبار و یا حسابداری و غیره). سئوال این است که این طور کد ها را در کجا قرار دهیم طوری که با کدهای CRUD ترکیب نشود؟لایه دامنه بهترین جا برای قرار دادن Logic برنامه است.در پایان این نوشتار می خواهیم با ماهیت اصلی لایه دامنه و کارکرد آن بیشتر آشنا شویم.لایه دامنه یک مدل شبیه سازی شده از شیوه عملکرد نرم افزار را در اختیار ما می گذارد. پیش از اینکه جلوتر برویم باید بدانیم مدل چیست، و چه کاربردی دارد. مدل یک نمونه کوچک و شبیه سازی شده از یک دنیای واقعی است. یک مدل سازه ماکارونی را در نظر بگیریدمدل سازه ماکارونیاین مدل 1. کوچک شده است2. شبیه سازه اصلی است3. برخی از مشخصه ها مانند میزان مقاومت در مقابل فشار را شبیه سازی میکندمدل موجود در لایه Domain هم باید دنیای واقعی را برای ما شبیه سازی کند(مثلا فرایندهایی که در یک فروشگاه اتفاق می افتد). اما این شبیه سازی چه ویژگی هایی دارد؟1. این شبیه سازی در حافظه اصلی کامپیوتر انجام می شود.2. ابزار ساخت این مدل Object Oriented است3. باید تا حد ممکن مشخصات، رفتار ها و اتفاقات دنیای واقعی را شبیه سازی کند.هرچه این مدل ها شباهت بیشتری به دنیای واقعی داشته باشد مدل ما غنی تر است. به مدل هایی که علاوه بر اطلاعات،منطق نرم افزار را هم در خود داشته باشند Rich Model می گویند.- یک Domain مجموعه ای از مدل ها یی است که میتوانند با هم تعامل داشته باشند.در واقع هر بار که کاربر یک درخواستی را به نرم افزار ارسال کرد ما یک نمونه از مدل های مورد نیاز Domain را در حافظه اصلی ایجاد می کنیم.توجه کنید که ما قطعا نمی توانیم یک مدل کامل از کل وضعیت جاری سیستم را در حافظه اصلی داشته باشیم(چون همه وضعیت سیستم در حافظه اصلی جا نمیشود). ما باید سعی کنیم فقط آن قسمت از وضعیت سیستم را که در انجام آن درخواست درگیر است را شبیه سازی کنیم.کاربر درخواست خود را به نرم افزار ما ارسال میکند. و ما سعی میکنیم مدلهایی که برای پردازش این درخواست نیاز است را شبیه سازی کنیم. می دانیم که همه درخواست های کاربران در پایان منجر به یک سری تغییر در وضعیت سیستم می شود. پس بعد از اینکه درخواست کاربر بر روی ِDomain شبیه سازی شده پردازش شد، مدل ما باید بتواند به ما بگوید که:آیا این درخواست قابل انجام است؟1. اگر قابل انجام نیست، به چه علت؟2. و اگر قابل انجام است، بطور دقیق چه تغییراتی در هنگام شبیه سازی در هر یک از مدلها ایجاد شد؟در حالت اول ما این موضوع را مستقیما به کاربر اطلاع می دهیم ولی در حالت دوم باید مجموعه عملیات های لازم برای اعمال واقعی تغییرات را (مانند یک یا چند عمل CRUD بر روی Database و یا فراخوانی یک وب سرویس) انجام دهیم.- اکنون منطق برنامه ما بدون وابستگی به Database یا هر سرویس خارج از RAM قابل Test کردن است- همچنین کد های مربوط به کار با پایگاه داده و فراخوانی یک سرویس خارجی از کد های منطق برنامه جداستبرای سادگی بیائید یک مثال ملموس تر را بررسی کنیمفرض کنید یک درخواست ثبت سفارش داریم، این درخواست با موجودیت های زیر سر و کار دارد(به عبارت دیگر این رکوردها در عملیات سفارش درگیر هستند)یک رکورد مشتریچندین رکورد محصولیک رکورد سفارشچندین رکورد ردیف محصول (منظور همان رکورد تعداد هر محصول است)پس برای شبیه سازی عملیات سفارش این کارها را انجام میدهیم:1. محصول های مورد تقاضا را از پایگاه داده دریافت می کنیم.2. رکورد مشتری را از پایگاه داده دریافت می کنیم3. یک رکورد سفارش جدید (در حافظه) ایجاد می کنیم.4. محصولات(دریافت شده از پایگاه داده) را به همراه تعداد آن به سفارش اضافه میکنیم5. مشتری(دریافت شده از پایگاه داده) را در سفارش ثبت می کنیم6. دستور صدور صورتحساب از سفارش را صادر می کنیم و یک رکورد جدید صورتحساب دریافت میکنیم .7. رکورد های سفارش و صورتحساب را در پایگاه داده ذخیره میکنیم.ما قطعا برای شبیه سازی مدل نیاز به همه مشتری ها و همه محصولات نداریم. بنابراین فقط محصولات و مشتری مد نظرمان را از پایگاه داده فراخوانی کردیمموارد 3 تا 6 تمام منطق ثبت سفارش را در خود دارد. همچنین تنها باعث تغییر بر روی مدل موجود در حافظه اصلی میشود، بدون وابستگی به هیچ چیز دیگر.افزودن موجودیت های جدید سفارش و صورتحساب تغییراتی است که باید در پایگاه داده ذخیره شود.موارد 1،2 عملیات های ساده ذخیره و بازیابی اطلاعات هستند و هیچ چیزی از منطق نرم افزار را در خود ندارند.جداسازی لایه منطق دامنه از منطق ذخیره و بازیابیشی گرایی(OOP) در لایه دامنههمانطور که گفته شد ابزار طراحی این مدل Object Oriented است. قطعا لایه دامنه بهترین جایی است که میتوانید از امکانات OOP استفاده کیند. زیرا مدل های کسب و کار فقط حاوی اطلاعات نیستند. آنها اغلب علاوه بر اطلاعات رفتار ها و رویداد هایی هم در خود دارند. و این فقط از عهده یک زبان Object Oriented برمی آید.نکته دیگری که در مورد این لایه باید بدانیم این است که مدل کسب و کار نباید اجازه دهد که در یک وضعیت نامعتبر قرارگیرد. برای همین رعایت اصل Encapsulation در این لایه بسیار حیاتی است.رصد کردن تغییرات(Changes Tracking) در لایه دامنهاگر یادتان باشد ما نیاز داشتیم که با توجه به وضعیت جاری سیستم یک مدل را شبیه سازی کنیم. این کار معمولا پیچیدگی خاصی ندارد. اطلاعات را در دریافت میکنید و مدلها را با آن اطلاعات شبیه سازی می کنیم. اما پس از اینکه مدل های دامنه شبیه سازی و درخواست بر روی آن پردازش شد، باید بتوانیم تشخیص دهیم که برای اعمال این تغییرات در وضعیت واقعی سیستم(مثل Database) چه کار هایی باید انجام شود. معمولا این کار به دو صورت انجام میشود.1. رویداد (Event) ها2. رصد کردن تغییرات (Changes Tracking)یکی از عناصر مهم لایه دامنه Event ها هستند، همه تغییراتی که باید به دنیای بیرون از مدل اعمال شود، تغییر در پایگاه داده نیست، بعضی از آنها چیزی فراتر از تغییر در پایگاه داده و CRUD هستند، مانند ارسال یک پیام کوتاه. در این موارد Event ها تنها راه ارتباط مدل با دنیای خارج از مدل است.اما Changes Tracking امکانی است که از طریق آن میتوانید تغییرات اعمال شده بر روی یک Object را رصد کنید(از طریق پروکسی کردن مدل ها). هرچند ابزار های زیادی برای این کار وجود دارد اما تقریبا تمام ORM ها هم از این امکان پشتیبانی میکنند و معمولا شما نیازی به پیاده سازی آن نخواهید داشت. شما با یک دستور Commit و یا Save Changes تمام تغییرات اعمال شده در مدل ها را در پایگاه داده خود ذخیره می کنید. مفاهیم اصلی در لایه دامنهمفهوم Entity با اختلاف مهمترین مفهمومی است که در طراحی لایه دامنه در اختیار داریم، مهمترین امکانی هم که در اختیار ما میگذارد این است که موجودیت ها را فقط توسط یک شناسه از هم تفکیک می کند.مفهوم ValueObject یک راهکار خوب برای جلوگیری از کدهای تکراری است. ValueObject کمک می کند نوع اطلاعات Entity محدود به داده های اولیه مثل عدد، رشته و بولین نباشد.مثلا آدرس ایمیل میتواند بجای یک رشته یک ValueObject باشد. در غیراین صورت مجبورید هر بار درست بودن ایمیل را بررسی کنید. و این کار ممکن است بار ها تکرار شود. با ValueObject آن را در یک نقطه انجام میدهید. لازم است بدانیم همانطور که داده های اولیه مثل رشته، عدد و غیره توسط محتوایشان از هم تفکیک می شود ValueObject ها هم با محتوایشان از هم تفکیک میشوند.منظور از Agreggate مجموعه Entity هایی هستند که همواره به همراه هم ذخیره و بازیابی میشوند. یعنی جدای از هم معنی ندارند و کاملا به هم وابسته هستند(مانند سفارش و ردیف محصول در مثال بالا). Entity که محور بقیه Entity هاست AgregateRoot نام دارد(مانند سفارش در مثال بالا). محمد رضا رحیمی محمد رضا رحیمی Mon, 29 Mar 2021 14:09:06 +0430 https://virgool.io/@mr_rahimi/%DA%86%D9%87-%D9%85%D9%88%D9%82%D8%B9-%D9%88-%DA%86%D8%B1%D8%A7-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A7%D8%B2-ddd-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-pprqeivpvrrm بعید است یک برنامه نویس Back-end باشید و طراحی دامنه محور (DDD) به گوشتان نخورده باشد. البته به نظر میرسد نقش DDD در میان برنامه نویسان به عنوان یک Buzzword خیلی پر رنگ تر از نقش آن به عنوان یک رویکرد عملی در طراحی نرم افزار باشد :) در هر صورت اینکه همه در مورد آن صحبت میکنند، دلیل خوبی برای یادگیری و بکارگیری آن نیست(البته کلا دلیل خوبی برای یادگیری هیچ چیزی نیست). شخصا همیشه پیش از اینکه یک روش یا ابزار جدید را یاد بگیرم باید درک کنم بدون آن قبلا چطور کارم را انجام می دادم، چه مشکلی با روش قبلی دارم و روش جدید چطور این مشکل را حل خواهد کرد.در مورد DDD همینگونه است. واقعیت آن است که DDD جادو نمیکند. فقط جایگزین رویکرد پیشین ما در طراحی سه لایه است. رویکردی که تنها از زاویه ذخیره و بازیابی اطلاعات به نرم افزار نگاه میکند. در این رویکرد منطق برنامه صرفا ترکیبی از عملیات های CRUD است.در پایان این نوشتار میخواهیم بدانیم DDD چه مشکلی را قرار است حل کند و به عبارت دیگر استفاده آن در چه نوع پروژه هایی معقول و منطقی است؟DDD می خواهد محوریت برنامه را از ذخیره و بازیابی اطلاعات به لایه ای به نام دامنه تغییر دهد. این نگرش در توسعه نرم افزار هزینه و فایده خود را دارد و قرار نیست به طرز جادوئی همه مشکلات ما را حل کند. برای درک اینکه DDD دقیقا چه مشکلی را حل میکند باید نگاهی به معماری سه لایه بیندازیم.رویکرد سنتی ما در طراحی نرم افزار چگونه استما معمولا به عنوان برنامه نویس هنگامی که نیازمندی های نرم افزار را از کارشناسان آن دامنه (مثلا دامنه سیستم انبارداری) دریافت می کنیم در ذهن خودمان مستقیما آنها را به ترکیبی از عملیات های ذخیره و بازیابی تبدیل میکنیم. و برنامه ما معمولا ترکیبی از این عملیات های ذخیره و بازیابی است که اصطلاحا CRUD نامیده میشود.تا زمانی که منطق نرم افزار ما در ذخیره و بازیابی اطلاعات دریافتی با کمترین تغییر ممکن در آن خلاصه میشود، این روش بسیار ساده و کارآمد عمل میکند.اما شرایطی را تصور کنید که مثلا تغییر در یک فیلد در یک جدول باعث تغییر چندین فیلد دیگر در جداول دیگر شود و به دنبال آن یک وب سرویس هم از یک برنامه دیگر فراخوانی شود. مثلا یک سیستم انبارداری را در نظر بگیرید. با خروج یک کالا از انبار باید چندین رکورد اطلاعاتی علاوه بر خود record کالا تغییر کند.میدانیم که محل قراردادن اینطور logic ها نه در لایه UI است نه در لایه Data Access. تنها گزینه، قرار دادن آنها در لایه Business Logic است. اما با افزایش تعداد این نوع نیازمندی ها، اتفاقی که رخ می دهد این است که منطق برنامه ما بصورت پراکنده و شلخته ای در برنامه درقالب عملیات های ذخیره و بازیابی پخش شده است. عملیات هایی که هیچگونه معنایی خارج از دنیای برنامه نویسی ندارند. این موجب میشود که1. خوانایی کد پائین بیاید2. کد های تکراری افزایش پیدا کند3. درک عملکرد برنامه بسیار پیچیده شود4. اشکال زدایی و نگهداری برنامه هزینه بر شوددر چنین شرایطی راه حل این است که منطق اصلی برنامه تا حد ممکن در یک نقطه متمرکز شود. متمرکز کردن Business Logic ها تا حد ممکن، مسئله ای است که DDD قرار است آن را حل کند. ( البته من از نگاه یک توسعه دهنده نرم افزار به DDD نگاه کرده ام و نه یک مدیر پروژه یا هر نقش سازمانی دیگری).راهکار DDD برای متمرکز کردن منطق برنامه چیستDDD بطور کلی تاکید می کند منطق برنامه را تا حد ممکن بجای قرار دادن در توابع لایه Business Logic در دامنه ای از مدل ها متمرکز کنید(اینکه چطور لایه دامنه را طراحی کنیم و چطور ارتباط آن با لایه های دیگر را برقرار کنیم موضوعی است که باید جداگانه به آن پرداخته شود) لایه دامنهمدل ها از طریق امکانات Object Oriented به ویژه با رعایت Encapsulation همیشه خود را در وضعیت معتبر حفظ خواهند کرد، فارغ از اینکه این تغییرات از چه نقطه ای از برنامه نشأت گرفته باشد. تغییر در یک مدل میتواند باعث دنباله از تغییرات در مدل های دیگر دامنه هم بشود. اما یکپارچگی و صحت وضعیت مدل ها حفظ خواهد شد. در طراحی این دامنه از مدل ها دغدغه های شیوه ذخیره و بازیابی اطلاعات و چگونگی تعامل با کاربر مدنظر نیست و تاکید بيشتر بر پیاده سازی نیازمندی های دامنه کسب کار است. لایه دامنه اغلب برای عملیات های Create, Update, Delete (که تغییر دهنده وضعیت سیستم هستند) کارکرد خود را نشان میدهد و معمولا در زمینه Read ارزش افزوده خاصی ارائه نمی دهد. یک نکته مهم دیگر درباره لایه دامنه وجود دارد. و آن این است که تمامی مدل ها و شیوه ارتباط آنها با هم به یک زبان قابل فهم و غیر فنی بیان میشود. بنابراین برای کسانی که با آن درگیر هستند، اعم از برنامه نویس ، تحلیلگر و کارشناسان آن دامنه کاملا قابل فهم است. به زبان ساده تر نام مدل(یا همان کلاس) ، behavior ها ، event ها و property های آن کاملا برای کارشناسان دامنه معنادار است.این موضوع کمک می کند که همه این افراد فارغ از مسائل فنی مربوط به خود نگاه مشترکی نسبت به هسته مرکزی نرم افزار داشته باشند. برخلاف روش قبل که هیچکس بجز برنامه نویس از لایه Business Logic چیزی نمی فهمید. این شفافیت در منطق برنامه قدرت حل مسئله را هم به طرز مطلوبی افزایش میدهد.بنابر این یک لایه تحت عنوان Domain که داخلی ترین لایه برنامه خواهد بود به برنامه ما اضافه خواهد شد. لایه بندی برنامه با رویکرد DDDاین لایه قلب نرم افزار ما خواهد بود. و هرگونه تغییری در منطق برنامه از انجا شروع میشود. مابقی قسمت های برنامه مانند بخش رابط کاربری(UI) یا ذخیره و بازیابی اطلاعات (Repository) در خدمت دامنه قرار دارند . بخش رابط کاربری درخواست های کاربر را به دامنه منتقل می کند و بخش ذخیره و بازیابی وظیفه Persistency دامنه را برعهده دارد. محمد رضا رحیمی محمد رضا رحیمی Sun, 07 Feb 2021 15:36:09 +0330