در این مقاله به بررسی تفاوت تفکر طراحی سطح بالای کلاسیک و DDD پرداخته میشود.
برای پیش بردن این مقاله، طراحی ها بر روی یک مثال کاربردی محدود صورت میگیرند. تلاش شده است که مثال طراحی شده نزدیک به حالت واقعی فرایندهای سازمانی بزرگ باشد تا ابعاد مورد نظر را بصورت کاملی شامل شود. همچنین تلاش شده است طراحی های انجام شده، درگیر با اصطلاحات تخصصی و الگوهای متداول مربوط به حوزه DDD نباشند، تا انتقال پیام به درستی بدون پرداختن به حاشیه های این موضوع، صورت گیرد. دراین طراحی سطح بالا به ارتباطات بخش های مختلف نرم افزار در سطح Solution توجه شده است. طراحی و تحلیل مدل های سطوح پایین مورد موضوع این مقاله نیست.
مثالی که طراحی روی آن صورت میگیرد شامل بخش های فروش، انبار، حسابداری و لجستیک یک فروش آنلاین میباشد. در این مثال طراحی، تنها سعی شده است دید تحلیلی خوانندگان در طراحی سیستم ها و ارتباطات بین سیستمی مورد موضوع قرارگیرد. بدیهی است که طراحی سیستم ها و معماری آنها مستلزم در نظر گرفتن نکات و ظرافت های بسیار زیادی است که گاهی حتی روش های بسیار خاصی محدود به همان شرایط را میطلبد.
شرح این فرایند بدین صورت است، که ابتدا تحویل کالاهای مورد نیاز توسط انبار صورت می گیرد، سپس بخش فروش اقدام به ارائه و فروش آن کالا ها میکند. پس از آن بخش لجستیک اقدام به تحویل و برنامه ریزی آن برای مرسولات میکند و با محاسبات هزینه و دریافتی ها در بخش حسابداری، فرایند ها کامل میشوند.
دیاگرام USE CASE زیر، سیستم های مورد بحث را نشان میدهد:
در این مثال در قسمت انبارداری به منظور کارهای ثبتی حسابداری، بعد از تحویل گیری کالاها و گرفتن موجودی در انبار، باید اسناد معادل آن ثبت شود. همچنین در قسمت های فروش و لجستیک نیز به ترتیب برای ثبت مبلغ فروش و هزینه ارسال کالا، نیاز به قسمت حسابداری است. همچنین در قسمت فروش پس از اینکه پرداختی کالای خریداری شده توسط مشتری انجام شد، باید از موجودی آن در انبار کم شود.
این مثال از این جهت که نیازمند ارتباط بین قسمت ها و سیستم های مختلف هست، دارای پیچیدگی میباشد که برای این منظور باید در سطح بالا، نوعی طراحی را انجام داد تا ارتباطات بین قسمت های مختلف را تامین و تسهیل کند.
در دیدگاه کلاسیک توسعه نرم افزار اساسا اهمیت خیلی زیادی به ساختارهای جدولی و نرمالیزه شده است. طبیعی است که در این حالت جداول شامل اطلاعاتی خواهند شد که تنها برای استفاده از یک قسمت نرم افزار نخواهد بود، بلکه ماژول های زیادی از اطلاعات داخل جداول استفاده میکنند. هرچند دیدگاه کلاسیک در چالش هایی مانند گرفتن گزارشات سریع ممکن است بخشی از اطلاعات جداول را از حالت نرمال خارج کند، اما توسعه ابزارها و امکانات پایگاه داده ایی در این جهت است که امکان گزارش گیری سریع را برای اطلاعات هرچه بیشتر نرمالیزه شده فراهم آورد.
با توجه به توضیحات داده شده، میتوان طراحی زیر را برای مثال گفته شده تصور کرد:
در این طراحی ارتباط بین ماژول ها و سیستم ها از طریق جداول واسط تعبیه میشود. همانطور که از جداول مشخص است به دلیل نرمالیزه شدن اطلاعات، هر قسمت برای انجام فرایند مخصوص به خود، نیازمند اطلاعات مربوط به قسمت های دیگر نیز هست. برای مثال قسمت لجستیک برای اینکه بتواند برای تحویل سفارشات یک روز، برنامه ریزی پیک ها را داشته باشد، به جدول آدرس های ثبت شده مشتریان برای یک سفارش نیازمند است. بنابراین در این طراحی، وابستگی فیزیکی و معنایی در اطلاعات اجتناب ناپذیر است و اطلاعاتی که در جداول نگهداری می شوند، بیشتر برحسب نرمالیزیشن و ماهیت آن ها طبقه بندی می شوند تا کاربرد و یا درک ماژول ها از آن ها.
1- به دلیل رعایت نرمالیزیشن به عنوان یک اصل در طراحی مدل های اطلاعاتی، با گذشت زمان و طراحی نیازمندی های جدید، اضافه شدن ستون های جداول منجر به بیشتر و پیچیده تر شدن اطلاعات جداول خواهد شد. به بیان دیگر رشد اطلاعات در جداول بیشتر بصورت عمودی خواهد بود. همینطور با بزرگتر شدن سیستم ها، سطوح نرمالیزیشن بیشتری نیز مورد نیاز است که ارتباطات جداول را پیچیده تر میکند.
2- وابستگی ایجاد شده باعث میشود که تغییرات در هر ماژولی بدون در نظر گرفتن تاثیرات آن در فرایند های دیگر ماژول ها، امکان پذیر نباشد.
3- نیازمندی ماژول ها به اطلاعات و نحوه ذخیره سازی اطلاعات در ماژول ها دیگر، باعث میشود عملا تیم های مستقل نرم افزاری شکل نگیرند. اغلب محصولات سازمانی ایی که به اینصورت توسعه داده و طراحی شده اند، بیشتر شبیه به یک تیم بسیار بزرگی هستند که تحت نظر یکی از افراد قدیمی و با سابقه آن جا هدایت می شوند. این ساختار تیمی و سازمانی، با تیم های کوچک و چابک مستقل نرم افزاری بسیار تفاوت دارد.
4- پیچیدگی و وابستگی های ایجاد شده مانع از پیشرفت طراحی به سمت معماری های مدرن نرم افزاری میشود.
5- در این بینش طراحی اساسا مدل های اطلاعات حول قوانین ثابتی همچون ارتباطات جدولی و نرمالیزیشن انجام میپذیرد. این رویکرد به دلیل ثابت بودن اصول و قوانین، عملا طراحی مدل های بهینه صورت نمی گیرد و به جای آن خلاقیت و تلاش ها در واکشی بهینه اطلاعات انجام می پذیرد. این روند موجب میشود که روز به روز وابستگی فرایندهای نرم افزار به امکانات و محدودیت های از پیش تعیین شده پایگاه داده بیشتر شود. این وابستگی گاهی آن چنان پیش میرود که برای طراحی فرایندهای نرم افزاری، ابتدا محدودیت های پایگاه داده مد نظر گرفته میشود و سپس طراحی انجام میپذیرد.
6- با اضافه شدن ماژول ها و امکانات دیگر، تعدد در جداول و ارتباطات بین آن ها به گونه ایی پیچیده میشود که عملا ذهن یک نفر برای بخاطر سپردن آن ها کافی نیست، یا به بیان دیگر در یک ذهن جا نمیشود. این در حالی است که یک سیستم مستقل با فرایند های مشخص نباید به چنین حد از پیچیدگی برسد.
7- در چنین محصولاتی تلاش توسعه دهندگان عملا به یادگیری هرچه بیشتر دیتابیس منتهی میشود تا اصول طراحی و بکارگیری آن ها در طراحی مدل های نرم افزاری و اطلاعاتی.
در مقایسه با دید کلاسیک در طراحی ارتباطات بین سیستمی، نرمالیزشن در این سطح اعمال نمیشود و مبنای ارتباطی بین آنها قراردادهای بین سیستمی است. این قراردادهای بین سیستمی بعد از انجام عملیات خاصی در یک سیستم، به دیگر سیستم ها اعلان میشود که هر کدام بصورت رویدادی خاص معرفی میشوند. یک سیستم پس از دریافت رویدادی، به میزان مورد نیازش از اطلاعات رویداد، در سیستم خود استفاده میکند. این استفاده می تواند همراه با پردازش روی اطلاعات نیز باشد.
سیستم ها برای مشخص کردن نیاز اطلاعاتی خود از یک مفهوم، به نقطه نظری که از آن مفهوم دارند رجوع میکنند. قبل از طراحی ارتباطات بین سیستمی لازم است با مفهوم نقطه نظر در دیدگاه DDD آشنا شویم.
نقطه نظر یک سیستم بیانگر ادراک آن سیستم از یک مفهوم است. برای روشن شدن این تعریف، اول به بررسی نوع فرایند های مد نظر در مثال، برای هر سیستم می پردازیم، سپس نقطه نظرات سیستم های مختلف را برای مفاهیم معرفی شده ، تحلیل و بررسی میکنیم.
در سیستم انبار فوکوس کار بر روی دریافت، انبار داری و تحویل دهی کالاها است. در این سیستم عمده فرایند های مهم عبارتند از: انبارداری، انبارگردانی و نقل و انتقالات درون سیستمی. سیستم انبار برای انجام فرایند های خود نیازمند کالا و مشخصات آن است. مشخصات مورد نیاز یک کالا برای انبار میتواند ابعاد، وزن، نوع، بسته بندی، رده ارزشی و تعداد کالا باشد.
در این سیستم تمرکز فرایند ها بر روی فروش و مسائل مربوط به آن است. بنابراین در این سیستم توجه اصلی بیشتر برروی ارزش، موجودی، مشخصات محتوایی کالا ها است. این سیستم بوسیله این اطلاعات میتواند فرایند های مربوط به فروش را انجام دهد.
در این سیستم برنامه ریزی و انجام فرایند های ارسال، بر اساس زمان مرسولات، مشخصات و اولویت های برنامه ریزی شده برای آن ها انجام میشوند. در این سیستم مشخصات وزنی، ابعادی، نوع کالاها، گیرنده و آدرس گیرنده اهمیت دارد.
در این سیستم تمرکز بر روی حساب و مشخصات مالی فرایند ها است. به بیان دیگر برای این سیستم تنها هزینه رد و بدل شده، طرفین حساب، تاریخ، و دلیل فرایند مالی مورد توجه هستند.
با توجه به تحلیل های بالا، نقطه نظرات و روند اطلاعات کالا در سیستم های مورد بحث به قرار زیر خواهد بود:
تصویر بالا نشان میدهد که نقطه نظر سیستم انبارداری از کالا، یک چیز قابل انبار کردن است بدین ترتیب تنها مشخصاتی از آن برایش اهمیت دارد که در فرایند های انبارداری به آن نیاز دارد. همچنین نقطه نظر سیستم فروش یک چیز فروختنی است. هرچند موجودی کالا در انبار برای این بخش مهم است، اما بدیهی است که اطلاعات انباری آن برای این بخش کافی نیست. این بخش باید برای فرایند های خود اطلاعات مورد نیاز برای کالاها، نظیر قیمت، تخفیفات و محتوا را در مرز سیستم خود تهیه و نگهداری کند. در سیستم لجستیک کالا معنای مستقلی ندارد و با مفهوم سفارش تعریف میشود. در این سیستم هر سفارش یک بسته برای تحویل است که کالا ها، محتویات بسته ایی هستند که باید به دست گیرنده برسد.
با توجه به توضیحات بالا، روند اطلاعات برای کالاها به صورت زیر خواهد بود:
1- پذیرش Stuff در سیستم انبار و اعلان رویداد پذیرش کالا
2- دریافت رویداد پذیرش کالا در سیستم فروش و تعریف Good برای فروش
3- تکمیل اطلاعات Good برای فرایند فروش و مشخص شدن آن برای موارد قابل فروش
4- فروش Good ها در یک سفارش و اعلان رویداد سفارش
5- دریافت رویداد سفارش توسط سیستم انبار و کثر موجودی Stuff های معادل در انبار
6- انتقال Stuff های کسر شده به بخش لجستیک
7- دریافت اعلان رویداد سفارش توسط سیستم لجستیک و تعریف Package آن به همراه Package Item های معادل
8- برنامه ریزی Package ها در سیستم انبار برای ارسال آن ها
9- ارسال یک Package توسط سیستم لجستیک و اعلان رویداد ارسال
با توجه به تحلیل های بالا نقطه نظرات و روند اطلاعات Party در سیستم های مورد بحث به قرار زیر خواهد بود:
تصویر بالا نشان میدهد که نقطه نظر سیستم فروش از یک Party یک مشتری است. همچنین در سیستم لجستیک مفهوم Party به معنی راننده است. این قضیه برای سیستم حسابداری اینگونه است که Party هرچیزی که باشد در این سیستم تنها میتواند یک طرف حساب مالی تلقی شود.
با توجه به توضیحات بالا، روند اطلاعات برای Party به صورت زیر خواهد بود:
1- تعریف مشتری در سیستم فروش و اعلان رویداد تعریف مشتری
2- دریافت رویداد تعریف مشتری توسط سیستم حسابداری و ایجاد حساب مربوط به آن
1- تعریف راننده در سیستم لجستیک و اعلان رویداد تعریف راننده
2- دریافت رویداد تعریف راننده توسط سیستم حسابداری و ایجاد حساب مربوط به آن
با توجه به بررسی نقطه نظرهای سیستم ها، طراحی سیسام ها و ارتباطات آنها در دیدگاه DDD به صورت زیر خواهد بود:
1- برای مفاهیم Party وکالا دیگر جداولی وجود ندارند و بجای آن، اطلاعات مورد نیاز از این مفاهیم بصورت Redundant درون هر سیستم ذخیره شده است. در این طراحی گرچه در سطح ارتباطی بین سیستم ها، نرمالیزشن انجام نشده، اما Redundancy ایجاد شده باعث این میشود که استقلال سیستم های اطلاعاتی محفوظ بماند. به عنوان مثال می توانیم سیستم فروش و انبار را مد نظر بگیریم. در طراحی جدید، جدا شدن ذخیره اطلاعات انباری کالا از فروش آن سبب میشود که فرآیند فروش کالا از فرایند های انبار مجزا شود، به گونه ایی که سبب میشود حتی بتوان از این سیستم فروش بصورت مستقل استفاده کرد. تا آن جا که سیستم فروش حتی میتواند بدون انبار نیز فرایند های خود را انجام دهد. این ویژگی در نرم افزارهای سازمانی بسیار اهمیت دارد که یک سیستم بتواند به صورت مستقل از دیگر سیستم ها کار کند و به راحتی قابل یکپارچه سازی با دیگر سیستم ها (حتی سیستم هایی که توسط دیگر شرکت ها عرضه شده اند) باشد.
2- ارتباطات بین سیستمی تنها بوسیله رویداد ها انجام میشود و تنها در موارد خیلی خاص، ارتباط مستقیم صورت می پذیرد.
3- در هیچ سیستمی در سطح معماری نرم افزار دسترسی مستقیم به زیرساخت های ذخیره و بازیابی اطلاعات دیگر سیستم ها وجود ندارد.
4- به خاطر وجود نقطه نظرهای هر سیستم از مفاهیم، هر کدام از سیستم ها میتوانند اصطلاحات و تعبیرهای مخصوص به خود را داشته باشد. این اسقلال معنایی و مفهومی در تمامی سطوح فنی و تحلیلی مرز یک سیستم وجود خواهد داشت. از این جهت به این استقلال معنایی و مفهومی، زبان فراگیر آن سیستم نیز گفته میشود.
تفاوت بسیار اساسی در طراحی های کلاسیک و DDD وجود دارد که اساسا بدون تغییر در بینش و تفکر به هیچ عنوان مزایای استفاده از DDD یا بوجود نمی آید و یا اینکه برای بهره بردن از آن ها به صرفه نیست. از مهمترین تفاوت های نگرش در این دو بینش نگاه به نرمالیزیشن و ارتباطات بین سیستمی است. در دیدگاه DDD ارتباطات بین سیستمی در ذخیره سازی اطلاعات محدود به نقطه نظر سیستم است. بازه ی ذخیره سازی و بازیابی این اطلاعات محدود به مرز کاربردی سیستم از اطلاعات است و به هیچ وجه دیگر سیستم ها را شامل نمیشود.
