به کارگیری فاز تاکتیک در DDD برای طراحی میکروسرویس‌ها

در مقاله قبلی که در ارتباط با فاز استراتژی صحبت کردیم ما یک نقشه کلی از اپلیکیشن همراه با زمینه‌های محدود شده یا Bounded Contexts طراحی کردیم و اولین مدل خود را در نهایت ایجاد کردیم. فاز بعدی که در این مقاله از آن صحبت خواهیم کرد فاز تاکتیک خواهد بود. ما زمانی وارد این فاز می‌شویم که در ابتدا نقشه خود را آماده کرده و سپس قصد داشته باشیم مدل طراحی شده را با دقت و درستی بیشتری کامل کنیم.

الگوهای تاکتیکال روی یک زمینه محدود شده اعمال می‌شود. در این معماری ما بیشتر تمرکز خود را روی موجودیت‌ها و توده‌ها قرار می‌دهیم و در نهایت تلاش می‌کنیم تا محدوده‌های تعیین شده را در طبیعی‌ترین و درست‌ترین حالت خود ایجاد کنیم.

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

نگاهی کلی به الگو تاکتیکال

در این بخش از مقاله قصد داریم یک نگاه کلی و خلاصه شده به الگوی تاکتیکال در DDD بیاندازیم. بنابراین اگر به خوبی با DDD و ساختار آن آشنایی دارید می‌توانید از خواندن این بخش اجتناب کرده و سراغ قسمت‌های دیگر مقاله بروید. برای توضیح دادن این الگو ابتدا نیاز داریم که سراغ یک تصویر کلی از این معماری برویم. در ادامه در ارتباط با بخش‌های مختلف این تصویر صحبت خواهیم کرد.

Entity یا موجودیت :Entity یک به بخشی از اطلاعات گفته می‌شود که دارای یک شناسه منحصر به فرد بوده و در گذر زمان از سیستم حذف نمی‌شود. برای مثال در یک اپلیکیشن بانکی، مشتری‌ها و حساب‌های آنان موجودیت‌ها را تشکیل می‌دهند. موجودیت‌ها دارای یکسری ویژگی هستند که در زیر می‌توانید این ویژگی‌ها را مشاهده کنید.

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

Value objects یا مقدار اشیاء: Value Object دارای هیچ شناسه یا ID نیست. در الگوی تاکتیکال این دسته از اطلاعات تنها زمانی ایجاد می‌شوند که مقدارهایی را به خاصیت‌های آن نسبت بدهیم. برای ایجاد یک Value Object نیاز است که یک نمونه جدید را ایجاد کنید، در این حالت مقدار قبلی از بین رفته و مقدار جدید جایگزین می‌شود. همچنین این دسته از داده‌ها قابلیت تکرارپذیری را داشته و می‌توانند در یک حلقه قرار بگیرند.

در Value Objectها شما می‌توانید متدهای مختلفی را تعریف بکنید. این متدها می‌توانند منطق اصلی یک Domain را تعریف بکنند. همچنین این موضوع را به یاد داشته باشید که متدها نباید هیچ Side Effectیی روی وضعیت شئ داشته باشند. چند مثال از این نوع داده‌ای شامل رنگ‌ها، تاریخ، زمان و واحدهای پولی می‌شود.

Aggregates یا توده‌ها: یک توده در مدل DDD وظیفه دارد تا یک مرزبندی مشخص و سازگار را در بین یک یا چند موجودیت مختلف ایجاد کند. هدف اصلی توده‌ها این است که متغیرهای ارسالی/دریافتی را مدل‌سازی کند. چیزهای مختلفی که در دنیای واقعی می‌بینیم از پیچیدگی‌های رابطه‌ای بسیار زیادی برخوردار هستند. مشتری‌ها سفارش‌ها را ایجاد می‌کنند، سفارش‌ها شامل محصولات هستند، هر محصول دارای توزیع کننده مربوط به خود است و این روابط می‌توانند بسیار بیشتر نیز باشند. اگر چنین روابطی را در اپلیکیشن‌مان پیاده‌سازی کنیم چه تضمینی برای همخوانی و سازگاری قسمت‌های مختلف وجود دارد؟ چگونه می‌توانیم این موارد را به درستی ردیابی کنیم؟

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

به عنوان یک نکته مهم این قضیه را در نظر داشته باشید که یک توده به سادگی می‌تواند سازگاری را به یک موجودیت بدون فرزند بیاورد. اما چیزی که توده‌ها واقعا در آن کاربردی هستند مرزبندی معاملات یا Transactionها است.

Domain Events یا رویدادهای دومین: رویدادهای دومین زمانی مورد استفاده قرار می‌گیرند که ما بخواهیم بقیه اجزاء یک سیستم را از اتفاق افتادن چیزی خبردار کنیم. همانطور که از نام این قسمت مشخص است تمام کارهایی که در این بخش اتفاق می‌افتد مربوط به خود Domain است. برای مثال اگر یک رکورد به یک جدول اضافه شود این رویداد مربوط به Domain Event نیست. اما یک بسته تحویل داده شد یک رویداد مربوط به دومین خواهد بود.

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

الگوهای DDD دیگری نیز وجود دارد که ما در این مقاله در ارتباط با آن‌ها صحبت نکرده‌ایم. اما مواردی که در این مقاله گفته شدند از جمله مهمترین موارد و الگوهای مربوط به DDD هستند.

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

اپلیکیشن تحویل بسته با پهپاد و اعمال الگوهای DDD

در قدم اول ما سراغ سرویس مرزبندی شده Shipping خواهیم رفت. اگر نمی‌دانید منظورمان از این سرویس چیست باید به مقاله قبلی بازگشته و مدل طراحی شده را مشاهده کنید.

• یک مشتری می‌تواند درخواست یک پهپاد را ارائه دهد تا چیزی برایش ارسال شود.
• ارسال کننده یک بارکد را ایجاد می‌کند تا روی بسته قرار دهد.
• یک پهپاد برای دریافت بسته از مسیر اصلی و تحویل آن به مسیر مقصد ارسال می‌شود.
• وقتی یک مشتری فرایند دریافت یک بسته را زمان بندی می‌کند اطلاعات کاملی از مسیر و تاریخچه‌های دریافتی را می‌تواند مشاهده بکند.
• زمانی هم که پهپاد در حال ارسال بسته است، مشتری خواهد توانست موقعیت زنده و دقیق پهپاد را مشاهده کند.
• تا زمانی که پهپاد بسته را تحویل نگرفته، مشتری می‌تواند درخواست خود را لغو کند.
• زمانی که تحویل محصول به صورت کامل انجام شد مشتری خبردار خواهد شد.
• ارسال کننده می‌تواند درخواست تاییدیه دریافت را از مشتری ارسال کند. در این حالت مشتری باید یک کاغذ یا چیزی شبیه به آن را در نهایت امضاء کند.
• کاربران می‌توانند تاریخچه دریافت‌های موفق را مشاهده کنند.

با توجه به سناریو بالا تیم توسعه موجودی یا Entityهای زیر را برای ایجاد این اپلیکیشن در نظر گرفته است:

• فرایند تحویل
• پکیج یا بسته
• پهپاد
• حساب کاربری
• تاییدیه
• نوتیفیکیشن
• بارکد

چهار مورد اول لیست بالا به عنوان توده‌های اپلیکیشن شناخته می‌شود. این موارد فرایند ارسال/دریافت داده را در خود باید با رعایت نهایت میزان همخوانی و سازگاری رعایت کنند. تاییدیه و نوتیفیکیشن فرزندهای موجودیت فرایند تحویل به حساب می‌آيند و بارکد نیز فرزند موجودیت بسته است.

Value Objectهای این طراحی شامل موقعیت مکانی، ETA، وزن بسته و اندازه بسته خواهد بود.

در تصویر زیر می‌توانید یک دیاگرام UML از توده مربوط به فرایند تحویل را مشاهده کنید:

در این سناریو ما دو رویداد دومین یا Domain Event خواهیم داشت.

• زمانی که یک پهپاد در حال پرواز است موجودیت پهپاد یک رویداد وضعیت ارسال می‌کند که در آن موقعیت مکانی و وضعیت خود پهپاد نشان داده می‌شود.
• موجودیت فرایند تحویل نیز اطلاعاتی از وضعیت تحویل پکیج را ارائه می‌دهد. برای مثال زمانی که فرایند تحویل یک بسته کامل شود این بخش اطلاعات مربوطه را ارسال می‌کند.

به عنوان یک نکته مهم این قضیه را در نظر داشته باشید که این رویدادها چیزهایی را به خروجی ارسال می‌کنند که برای مدل دومین مهم است.

تیم توسعه متوجه قضیه‌ای شده که برخی از قسمت‌هایی که برای کارکرد کامل اپلیکیشن نیاز است را جا انداخته است. به همین دلیل تیم توسعه دو Domain Service را به طراحی اضافه کرده که یکی از آن‌ها را Scheduler و دیگری Supervisor نام دارد. سرویس اول وظیفه زمان بندی و سرویس دوم وظیفه مانیتور کردن وضعیت پهپاد و تحویل بسته را بر عهده دارد. در تصویر زیر ساختار دقیق این قضیه را می‌توانید مشاهده کنید:

در مقاله بعدی ما سراغ تعریف مرزبندی‌ها برای هر میکروسرویس خواهیم رفت.