https://virgool.ir/feed/@ElnazBaktashfa2026-11-11 11:52:01https://files.virgool.ir/upload/users/869476/avatar/QHXzdE.jpeghttps://virgool.ir/@ElnazBaktashhttps://virgool.ir/@ElnazBaktash/بخش-دوم-ddd-آشنایی-با-bounded-context-و-context-map-g7smmy11kpwcسلامی دوباره با بخش دوم Domain Driven Designدر بخش اول در مورد مفاهیم کلی و پایه ای DDD صحبت کردم، در این بخش تصمیم دارم در مورد دو مفهوم Bounded Context و Context Map صحبت کنم.در بخش اول یک موضوعی رو عنوان کردم با مضمون اینکه هروقت از DDD صحبت شد یاد شکستن بیفتید. برای اینکه این موضوع رو بهتر درک کنیم به مکانیزم عمل کردی مغز انسان دقت کنید، وقتی مغز انسان با یک مسئله پیچیده روبه رو میشود آنقدر آن مسئله را به مسئله های کوچکتر میشکند که راه حل آن قسمت های کوچکتر را در حافظه اش داشته باشد، بعد همه قسمت ها را با هم ادغام میکند تا به جواب مسئله اصلی برسد. به عنوان مثال جمع دو عدد را در نظر بگیرید مثلا 100 + 100 حاصل این مقدار برای خیلی از انسان ها بدون استفاده از ماشین حساب بدیهی است چون به عنوان یک مسئله بدون پیچیدگی برای مغز ثبت شده است ولی حالا حاصل جمع 1578 + 1376 را در نظر بگیرید خیلی از انسان ها وقتی با این جمع رو به رو میشوند با یک مسئله پیچیده رو به رو شدند و در نگاه اول پاسخ این عبارت را نمیدانند در این حالت مغز انسان برای حل این مسئله آن را به مسئله های کوچکتر قابل حل خرد میکند و در نهایت با ادغام مسئله های کوچکتر پاسخ این مسئله را پیدا میکند.حال منظور از مسئله پیچیده چیست؟ در واقع هرچیزی که درک آن در حوزه مسئله (problem space) برای مغز سخت باشد یک مسئله پیچیده است.با توجه به تئوری پیچیدگی (Complexity Systems Theory) به سیستمی پیچیده میگویند که از اجزای زیادی تشکیل شده باشد و این اجزا بهم وابستگی داشته باشند. به طور کل Sub Domain ها در فضای مسئله وجود دارند (Problem Space) که معادل آن ها در فضای راه حل(Solution Space) یعنی زمانی که میخواهیم این Sub Domain ها را به کد تبدیل کنیم تبدیل به Bounded Context میشوند.تفکر DDD با استفاده از الگوهای استراتژیک و اصل خرد کردن تلاش میکند که Domain پیچیده را به یکسری Sub Domain با پیچیدگی کمتر تبدیل کند و وابستگی بین آن ها را درست مدیریت کند. با توجه به این تعاریف به این نتیجه میرسیم که Sub Domain ها در فضای مسئله وجود دارند (Problem Space) که در فضای راه حل(Solution Space) یعنی زمانی که میخواهیم این Sub Domain ها را به کد تبدیل کنیم تبدیل به Bounded Context میشوند. در حالت ایده آل اینگونه است که به ازای هر Sub Domain یک Bounded Context وجود داشته باشد ولی ممکن است در عمل اینگونه نباشد.طبق تعریف آقای Bounded Context ،Eric Evans را به غشای سلول بدن تشبیه کرده است. در اصل این مرز برای این وجود دارد که پیچیدگی های هر Sub Domain به بیرون از آن نشت نکند همان طور که اگر غشای سلول از بین برود دیگر سلولی وجود نخواهد داشت. همچنین Eric Evans در کتاب خود مثالی از فرش کردن یک واحد ساختمان را زده است، که اتاق ها و سالن این ساختمان که قرار است فرش شوند همان SubDomain های ما محسوب میشوند و فرشی که برای آن ها استفاده میشود همان Bounded Context میباشد. در این مسئله، میتوان برای هر اتاق یک فرش جداگانه در نظر گرفت (مورد ایده آل) و هم از یک فرش برای دو اتاقی که رو به روی هم قرار گرفته اند استفاده کرد.(یک Bounded Context برای دو Sub Domain) و این کاملا به فضای Domain بستگی دارد.یک موجودیت در BC های مختلف معناهای مختلفی میدهد و طبق این معنای متفاوت، رفتارها و خصیصه های متفاوتی را هم به همراه خواهد داشت. برای مثال یک شرکت را در نظر بگیرید که از یک بیمه خاص استفاده میکنند. یک فرد در حوزه شرکت به عنوان کارمند شناخته میشود و ویژگی های خاص خود را دارد و همین فرد در حوزه شرکت بیمه ای که از آن استفاده میکند به عنوان بیمه شده تلقی میشود و ویژگی های متفاوتی از حوزه شرکت را به همراه دارد. هر BC معماری خاص خود را دارد حتی میتواند دیتابیس مستقل داشته باشد و حتی بسته به تصمیم شرکت میتوان توسعه و پابلیش هر BC را به عهده تیم های مختلف گذاشت. (عکس برگرفته شده از کتاب Practicing Domain driven design)ارتباط بین Bounded Context ها آن ها با روش های متفاوتی با هم در ارتباط هستند و از هم سرویس میگیرند. BC ای که سرویس دهنده است به عنوان UpStream شناخته میشود و BC ای که سرویس گیرنده است و به رفتار و یا دیتای UpStream وابسته است به عنوان DownStream شناخته میشود. نوع ارتباط های بین BC ها به موارد مختلفی تقسیم میشود که من چند مورد از آن ها را در این مقاله عنوان میکنم:روش اول Seprate Ways: در واقع این همان ایده دوری و دوستی است. یعنی برخی اوقات به دلیل هزینه بالا ارتباط بین تیم ها و یا همان Bounded context ها، شرکت تصمیم به این موضوع میگیرد که هر تیم راه خود را برود و روی هدف خود تمرکز کند.روش دوم Customer - Suplier :در این نوع ارتباط BC ای که به عنوان سرویس دهنده میباشد به دنبال رفع نیازمندی های BC سرویس گیرنده است و به نوعی آن را مشتری خود میبیند به همین دلیل نیازمندی های BC سرویس گیرنده برروی اولویت ها و برنامه ریزی های تیم سرویس دهنده تاثیر میگذارد.روش سوم Conformist: در این نوع ارتباط نیازمندی های تیم سرویس گیرنده دغدغه ای برای تیم سرویس دهنده ایجاد نمیکند، در واقع تیم سرویس گیرنده خودش را باید با تیم سرویس دهنده وفق دهد.روش چهارم Partnership:در این نوع ارتباط، همکاری تیم سرویس دهنده و سرویس گیرنده در حد زیادی وجود دارد و تفاوت آن با ارتباط Customer-Suplier در این است که تیم سرویس دهنده و سرویس گیرنده برروی BC هایی کار میکنند که یک هدف مشترک را دنبال میکنند، در حدی که حتی گاهی اوقات پابلیش آن دو باید با هماهنگی هم صورت گیرد.روش پنجم Anticorruption Layer:در واقع یک لایه مترجم سمت سرویس گیرنده میباشد که از رخنه کردن مفاهیم و زبان BCسرویس دهنده به داخل BC خود جلوگیری میکند. در اصل به عنوان نوعی فیلتر برای BC مطرح میشود.(به نوعی الگوی Adapter میباشد)روش ششم Shared Kernel:وقتی قسمتی از مدل بین BC ها از نظر مفهوم و منطق یکسان باشد آن را به عنوان یک بخش مشترک در نظر میگیریم. این الگو حتما باید با وسواس و دقت خاصی مورد استفاده قرار بگیرد چون باعث بوجود آمدن وابستگی میشود.روش هفتم Published language :در اصل BC ای که ارائه دهنده سرویس میباشد به همراه سرویس، یک مستندی از سرویس های خود در اختیار سرویس گیرنده قرار دهد.روش هشتم Open Host Service :در این نوع ارتباط سرویس دهنده سرویس مورد نظر خود را در یک جایی Hostکرده و در قالب API به همراه یک مستند (Published language) در اختیار سرویس گیرنده ها قرار دهد.با توجه به مفاهیم گفته شده در مورد Bounded Context ها وقتی از ارتباط بین BC ها یک مدل تصویری غیر رسمی ایجاد میکنیم که نحوه ارتباط آن ها را برای ما شفاف تر کند را اصطلاحا Context Map مینامیم.Context Mapجمع بندی: در این قسمت با مفهوم Bounded Context و Context Map آشنا شدیم. تعریف BC محدوده منطقی حول مدل دامنه ایجاد می‌کند و قابلیت درک صحیح و استفاده صحیح از زبان را فراهم می‌آورد.ElnazBaktashElnazBaktashFri, 21 May 2021 21:39:44 +0430https://virgool.ir/@ElnazBaktash/بخش-اول-domain-driven-design-مقدمه-و-مفاهیم-کلی-zkgdixz6bk5iسلام مدتی بود که میخواستم راجع به Domain Driven Design بنویسم که بالاخره تصمیممو گرفتم و شروع کردم. از اینجا شروع کنیم که ببینیم اصلا Domain Driven Design چیست؟ Domain Driven Design که به اختصار بهش DDD میگن اولین بار در سال ۲۰۰۳ توسط آقای Eric Evans در کتاب Domain-driven design مطرح گردید. این رویکرد در سال های گذشته به شدت توجه جامعه نرم افزاری رو به خودش جلب کرده. در اصل DDD یک نوع تفکر و یا رویکردی برای تولید و توسعه ی نرم افزارهای بزرگ با فرآیندها و قوانین زیاد و پیچیده میباشد که از قسمت تحلیل گرفته تا قسمت کد نویسی یک محصول همراه ماست در اصل در دو قسمت استراتژیک و تکنیکال به ما ایده میده (البته خود آقای Eric Evans در کتابش بیشتر در مورد مفاهیم استراتژیک صحبت میکنه)و تمرکز اصلیش هم روی بیزینس اصلی نرم افزاریه که میخواهیم بنویسیم که همون Domain ماجراست. در واقع کار DDD از یک آرزو یا مشکل بیزینسی (Problem Domain) شروع میشود.تعریف خود آقای Eric Evans از دامنه یا همون Domain به شرح زیره: "محدوده‌ای که کاربر برای برنامه اعمال می‌کند".همونطور که تا الان صحبت کردم و متوجه شدیم DDD برای محصولاتی که بیزینس پیچیده ای دارن خیلی مفیده لذا استفاده از آن در پروژه های کوچک و ساده و یا پروژه هایی که صرفا نیاز به ذخیره و خواندن اطلاعات دارند و Business خاصی ندارند، ممکن است تنها زمان و هزینه ی پروژه را افزایش داده و مزیتی خاصی هم به همراه نداشته باشد.از دیگر زوایایی که DDD روی آن تاکید خاصی دارد تعامل سازنده و بهینه بین برنامه نویسان و افراد متخصص دامنه (Domain) که بهشون Bussiness Expert گفته میشه داره. به خاطر همین ایجاد یک زبان مشترک به نام Ubiquitous Language در مورد مفاهیم دامنه امری الزامی است. که این زبان مشترک رو هم در مستندات تحلیل میبینیم و هم در کد. در اصل یکی از قدرت های DDD استفاده از زبان مشترک است. برای مثال به دو تصویر زیر دقت کنید، تصویر اول یک سناریو برای ارسال و تحویل پیتزا میباشد و تصویر دوم پیاده سازی متد همین سناریو میباشد. همان طور که میبینیم در هر دو تصویر سعی بر این آمده است که از زبان مشترک استفاده شود. (تصاویر برگرفته از کتاب The Anatomy Of Domain Driven Design)تصویر اول: (مستند سناریو تحویل پیتزا)تصویر دوم : (پیاده سازی سناریو تحویل پیتزا)هروقت از DDDصحبت شد یاد شکستن بیوفتید در واقع DDD همه چیز رو میشکنه یعنی اینکه مسائل رو میشکنه تا راحتتر باهاشون برخورد کنه مثل Knowledge Crunching(شکستن دانش) و یا اینکه دامنه رو به یکسری SubDomain میشکونه و یا راهکارهایی برای تقسیم نرم افزار به بخش های جدا و مستقل از هم و همچنین ارتباط این بخش ها با یکدیگر ارائه میکند. این امر سبب می شود تا فرآیند توسعه ی نرم افزار به صورت موازی بین چند تیم انجام شده و همچنین معماران سیستم را قادر می سازد تا از معماری ها و تکنولوژی های مختلف در بخش های مختلف استفاده نمایند. اگه بخوام یکم بیشتر راجبه SubDomain ها صحبت کنم میتونم بگم اون ها رو به 3 دسته تقسیم کردن:1- دامنه اصلی (Core Domain): محدوده اصلی دانش و مسئله ای که با اون سروکار داریم رو بهش میگن دامنه اصلی. بیشترین تلاش و هزینه هر شرکتی روی دامنه اصلیه حتی خیلی از شرکتها نیروی های ماهرشون رو روی این قسمت میزارن که کار کنند در اصل اینجوری بگم که کلید موفقیت هر پروژه موفقیت در Core Domain هستش.2- دامنه پشتیبان و دامنه عمومی(Supporting Domain و Generic Domain):در طول یک پروژه ممکن است با بخش‌هایی مواجه شویم که اصل کسب و کار را تشکیل نمی‌دهند ولی وجودشون برای اینکه کار اصلی دامنه به هدف برسه ضروری و لازمه و حتی میتونیم این بخش ها را از شرکت های دیگه ای خریداری کنیم. مثل ارسال ایمیل یا اس ام اس ...در واقع انتخاب sub domainها یک موضوع کاملا نسبی است و هیچ قاعده و قانونی نداره در واقع هیچ انتخاب قطعی درست یا غلط راجبش وجود نداره و کاملا به تیم بستگی دارد.تمام مفاهیمی که تا به اینجا مطرح شد در فضای مسئله بودند و هنوز وارد فضای راه حل نشدیم. در اصل تشخیص subdomain ها و یا زبان مشترک.... در فضای تعریف خود مسئله است(problem space) نه در فضای راه حل مسئله.(solution space).در این مقاله من سعی کردم یکسری از مفاهیم اولیه و کلی که مربوط به DDDبود رو عنوان کنم حالا تو قسمتای بعدی سعی میکنم بیشتر در مورد مفاهیم استراتژیک و تکنیکال صحبت کنم و بیشتر وارد فضای حل مسئله شیم.ElnazBaktashElnazBaktashFri, 14 May 2021 12:01:42 +0430