مفهوم DDD یا Domain Driven Design در سال 2003 توسط آقای Eric Evans مطرح شد. در اینجا به بررسی DDD در دو حوزه Strategic Design و Tactical Design می پردازیم.
Domain-Driven Design
Tackling Complexity in the Heart of Software
غلبه بر پیچدگی در قلب نرم افزار، عنوان کتاب آقای Eric Evans معروف به کتاب Blue Book است.
اولین موضوعی که مطرح می شود، بررسی واژه Complexity و تئوری آن است.
در نظر بگیرید، قصد تولید یک وبسایت برای نمایش یکسری محتوا داریم. از طرفی می خواهیم یک نرم افزار تامین و تدارکات با امکاناتی مثل فرآیند خرید و فروش، انبار، پخش و امکاناتی از این قبیل را برای یک سازمان نیز بنویسیم. برای نوشتن وبسایت، چالش و نگرانی خاصی نخواهیم داشت اما به نرم افزار تامین و تدارکات به عنوان یک پروژه بزرگ نگاه می کنیم و ممکن است نگران شویم. گاها از شکست و هزینه نگهداری بالای این گونه نرم افزارها می شنویم. بین این وبسایت و نرم افزار چه تفاوتی وجود دارد که باعث ترس و نگرانی ما می شود؟
موضوعی که باعث ایجاد تفاوت میان این دو وجود دارد، domain و business است.
ممکن است سخت بودن کاری به معنای پیچیده بودن آن نباشد. بنابراین وقتی در مورد complexity صحبت می کنیم، با مساله ای روبرو هستیم که المان های زیادی دارد که با هم روابط دارند و قوانین و فرآیندهای متفاوتی در حول این قوانین وجود دارد.
برای مثال بازی شطرنج به خاطر المان های زیادی از تعداد مهره ها و حالت های حرکت و قوانینی که حول محور آنها وجود دارد، می تواند به عنوان یک کار پیچیده باشد.
نکته ای که در پروژه های domain complexity وجود دارد این است که ما هیچ وقت پیچیدگی ذاتی را نمی توانیم از بین ببریم. گاهی پیچیدگی تصادفا توسط ما اتفاق می افتد. اما بعضی از مساله ها ذاتا پیچیده هستند و ما می توانیم با تکنیک هایی بر پیچیدگی غلبه کنیم.
مفهوم DDD، به طور خلاصه یک فلسفه فکری و تفکر برای غلبه بر پیچیدگی در پروژه هایی است که ماهیتا پیچیدگی دارند.
Domain
به محدوده ای از دانش یا فعالیت، domain می گویند. همچنین سوژه ای که می خواهیم از آن یک نرم افزار ایجاد کنیم. برای مثال حسابداری، انبارداری، تدارکات، تامین، خزانه داری و غیره که ممکن است روی آن ها کار کرده باشیم.
Domain Model
در domain model، از روی یک domain که در واقعیت وجود دارد یک مدل نرم افزاری طراحی می کنیم. مجموعه ای از کلاس ها و ارتباطاتی که می تواند جواب نیازمندی های ما را بدهد.
ساخت یک مدل unique که با دقت بالایی در قلب یک نرم افزار طراحی شده است، یکی از اصلی ترین نقاط تمرکز در DDD است.
Ubiquitous Language
یکی از عوامل پیچیدگی که در یک نرم افزار وجود دارد، موضوع Language است. در پیچیدگی زبانی با چند مساله روبرو هستیم. اولین مساله که خود را در نرم افزار نشان می دهد، وجود دو دسته آدم از سرزمین های متفاوت است.
دسته اول آدم هایی هستند که به آن ها Domain Expert گفته می شود. کسانی که در مورد یک domain تسلط دارند و متخصصین آن حوزه هستند و قوانین و فرآیند آن را می شناسند. اگر در مورد domain حسابداری صحبت کنیم، حسابدارها می توانند به عنوان domain expert باشند. دسته بعدی تیم توسعه است. dictionary بین این آدم ها در مورد یک domain، متفاوت است و می تواند باعث پیچیدگی شود.
بنابراین موضوع Ubiquitous Language یا زبان فراگیر، در DDD مطرح می شود. DDD معتقد است، زبان فراگیر زبانی است که شما در business, documentation, test, model, code بصورت یکسان آن را می بینید و تغییر نمی کند.
از اشتباهاتی که به عنوان یک برنامه نویس ممکن است انجام داده باشیم، نگاه کردن به تمام عملیات های سیستم بصورت CRUD است. به این صورت که در business یکسری مفاهیم داریم و در کد مفاهیم متفاوتی داریم. برای مثال مفهومی که در business به عنوان بستن حساب دیده می شود را در کد به عنوان یک update بر روی حساب در نظر می گیریم. تفکر داده محوری، رایج ترین موضوعی است که بین آدم ها شکاف ایجاد می کند.
Perspective
یکی دیگر از عوامل پیچیدگی، Perspective یا زاویه نگاه است. واقعیت از زاویه نگاه ناظر تعریف می شود. برای مثال، با هدف نوشتن یک نرم افزار تدارکات وارد یک سازمان می شویم. اگر یک laptop را در نظر بگیریم و از یک انباردار در مورد مشخصات سخت افزاری آن سوال کنیم، احتمالا جوابی که می گیریم صرفا در راستای طرز نگهداری آن است. یا اگر از واحد پخش این سوال را بپرسیم باز هم جواب نمی گیریم و صرفا طرز حمل آن را می داند. و یا واحد مالی فقط مبلغ آن را می داند.
بنابراین perspectiveهای متفاوت، یکی از عوامل مهم در پیچیدگی است و باعث متفاوت شدن زبان آدم ها نیز می شود. در لحظه وارد شدن به یک سازمان، در ورودی از نگاه نگهبان ما یک مراجعه کننده هستیم و در واحد فروش، یک مشتری هستیم.
در نهایت در ساخت مدل product، سعی می کنیم perspectiveهای متفاوتی که دریافت کرده ایم را در آن اضافه کنیم. در حالی که نیازها را نمی تواند جواب دهد و پیچیدگی ایجاد می کند. همین مساله در language هم وجود دارد. فرض کنید در انبار به این مدل کالا می گویند، در فروش محصول گفته می شود و در پخش مرسوله گفته می شود.
به طور کلی، DDD به دو بخش Strategic Design و Tactical Design تقسیم می شود.
در strategic design تمرکز ما بر روی شکوندن یک مساله بزرگ به اجزای کوچک تر و حل مسائل کوچک تر است. برای مثال در مساله تدارکات، می توانیم آن را به بخش های تامین، پخش، کنترل موجودی، انبار و بخش های مختلفی تقسیم کنیم.
در tactical design، وارد جزئیات هر کدام از اجزای داخلی و طراحی آن ها می شویم. برای مثال در بخش inventory یا کنترل موجودی، به یکسری مفاهیم مثل Check-In, Check-Out, Stock و اجزای مختلفی می رسیم.
Subdomain
یک domain معمولا از تعدادی Subdomain تشکیل می شود. مثالی که برای سامانه تدارکات زده شد را در نظر بگیرید. هر subdomain نسبت به حوزه های دیگر می تواند language و domain expert و همچنین value یا ارزش متفاوتی داشته باشد.
بنابراین strategic design بر روی شناسایی حوزه های مختلف، ارزش گذاری strategic بر روی بخش ها و ایجاد تیم برای توسعه پروژه ها تمرکز می کند. بخشی که business value بالایی دارد را مشخصا به تیم ضعیف نمی دهیم.
در تصویر زیر یک مثال از یک فروشگاه اینترنتی را ملاحظه می کنید.
در این فروشگاه قسمت های تامین، انبار، ارسال، اطلاع رسانی، فروش و بخش مختلف دیگری را مشاهده می کنید.
همانطور که گفته شد، subdomainها از لحاظ ارزش گذاری برای ما ارزش یکسانی ندارد. در نتیجه subdomainها به سه دسته تقسیم می شوند.
دسته اول core domain است که بیشترین business value در آنجا اتفاق می افتد. بنابراین ممتاز شدن در core domain باعث موفق شدن business می شود. برای مثال برنامه تاکسی اینترنتی را می توانیم در نظر بگیریم. هدف ما نوشتن بخش پشتیبانی سیستم نیست. هر چند که این قسمت هم در برنامه قرار می گیرد. به subdomainهایی core domain گفته می شود که بخش اصلی سیستم ما را تشکیل می دهند. با موفقیت در این حوزه می توانیم به موفقیت تجاری و مالی برسیم. بنابراین شناسایی core domain از لحاظ strategic اهمیت دارد. ازین خاطر، بهترین تیم، معماری و بیشترین توجه را به core domain خواهیم داشت.
برای اینکه یک core domain بتواند به اهداف خود برسد، به دو نوع subdomain دیگر به نام های supporting domain و generic domain نیاز خواهد داشت.
وجود supporting domainها برای core domain الزامی است. به این دلیل که بخش هایی از business را cover می کند که بدون وجود آن ها، core domain نمی تواند فعالیت کند. برای مثال در یک سامانه فروش، وجود انبار بسته به نوع business می تواند الزامی باشد.
وجود generic domainها نیز الزامی است اما در این حوزه نیاز ما general است و به طور مستقیم به operationهای core domain متصل نیست. برای مثال وجود یک سیستم اطلاع رسانی در سامانه فروش، جزو فرآیند اصلی نیست.
وجود هر سه نوع subdomainها برای یک سیستم الزامی است. supporting domain و generic domainها می توانند خریداری شوند و تمرکز روی core domain باشد که برای ما یک value ایجاد می کند.
توجه داشته باشید که در طول عمر یک پروژه، ممکن است اتفاقی مانند تشخیص اشتباه معماری یا تغییر نیاز مشتری، در پروژه بیافتد که یک subdomain از نظر strategic تبدیل به core domain شود.
