انجمن برنامه نویسان البرز

تبلیغات

تفاوت های انواع مدل در Domain Driven Design

تفاوت های انواع مدل در Domain Driven Design


کلمه “مدل” معمولا شبهاتی را در ذهن برنامه نویسان سطح بالا ایجاد میکند.
مدل در واقع چندین نوع دارد که در این مقاله به آن میپردازیم و به واسطه این توضیحات، کمی در رابطه با مبحث Domain Driven Design صحبت میکنیم.
چنانچه با این نوع معماری، آشنایی کافی ندارید، در حد مقدمات، دانستن این مطلب کافی است که Domain Driven Design یا DDD در واقع یک روش برنامه نویسی مبتنی بر دامین است. به این معنا که در این روش، سه لایه اصلی وجود دارد. پایین ترین لایه که Data Layer نام دارد و در واقع مرز داخلی سیستم ما با سایر سیستم ها است. مثلا با دیتابیس یا یک سرویس. این لایه وظیفه مدیریت دیتا را بر عهده دارد و شامل کدهای لاجیک و محاسباتی نیست. تکنولوژی ها و استانداردهایی که در این لایه وجود دارند، ORM و Unit Of Work و Repository Pattern و… هستند.
لایه بالاتر و اصلی، Domain نام دارد که مغز و لاجیک نرم افزار در آن وجود دارد. Domain شامل Validation ها، محاسبات، متدهای Custome و … است.
نهایتا بالاترین لایه و مرز خارجی نرم افزار ما View یا همان UI است که مرز ارتباطی نرم افزار با کاربر است.
همانطور که گفتیم، مدل ها انواعی دارند:

EntityModel

یک مدل Entity در واقع، کلاسی است که نمایش دهنده یک Row در دیتابیس است. این مدل لزوما همیشه با یک دیتابیس در ارتباط نیست. گاهی متصل به یک سرویس است و یا متصل به منابع دیگری است. نکته مهم این است که Entity Model در واقع نماینده یک فیلد اطلاعاتی، مثلا یک سطر در دیتابیس است. با توجه به این نکته، مشخص است که Entity Model در لایه Data Layer قرار دارد. معمولا ID دارد. مثلا StudentID. در واقع برای مثال، کلاس Student که یک Entity در DataLayer است، با اطلاعات یک Row در جدول Student دیتابیس، پر میشود.

Domain Model

در مرحله قبل دیدیم که یک Entity Model توسط اطلاعات دیتابیس پر میشود. حالا نیاز داریم که اطلاعات Fetch شده را به لایه بالاتر منتقل کنیم. یک قانون کلی در DDD وجود دارد: هیج لایه ای مستقیما با مدلی که از لایه پایینی دریافت کرده است، کار نمیکند. بنابراین، قرار نیست لایه Domain مستقیما با یک Entity Model کار کند. پس باید چه کار کنیم؟ راه حل این است که تمام لایه ها، علاوه بر مدل ها، کلاس هایی با نام سرویس دارند. یکی از وظایف سرویس ها، تبدیل مدل ها به یکدیگر است. برای مثال، Domain Layer یک سرویس Domain Service دارد. این سرویس، یک Entity Model را که از لایه Data میگیرد، به یک Domain Model تبدیل میکند تا لایه دامین، از آن استفاده کند. بنابراین، لایه دامین، به هیچ وجه مستقیما با Entity Model کار نمیکند. متقابلا، در مسیر برگشت هم، همین اتفاق می افتد. Domain Service یک Domain Model را به یک Entity Model تبدیل میکند و به لایه Data پاس میدهد.
پس Domain Model یک کلاس است که در لایه Domain استفاده میشود.

View Model

دقیقا شبیه به پارا گراف بالا، View Model کلاس مدل مربوط به لایه View است. پس هر لایه ای مدل خاص خودش را دارد. View Model وظیفه ارائه اطلاعاتی را دارد که به کاربر نمایش داده میشوند یا از کاربر گرفته میشوند.

سرویس ها:
لایه های Domain و View هر کدام، سرویس هایی برای تبدیل مدل ها دارند. بنابراین وظیفه Domain Service، تبدیل Entity Model به Domain Model و بالعکس است.
وظیفه Frontend Service، تبدیل Domain Model به ViewModel و بالعکس است.

نکته مهم اینکه سرویس ها فقط بلد هستند با مدل ها کار کنند. و وظایفی مثل Validation و … به عهده خود مدل است. مثلا اگر بخواهیم StudentDomainModel را بدون ست کردن پراپرتی ها استفاده کنیم، مدل Exception میدهد.

دقت کنید که در معماری Domain Driven Design همانطور که از اسم آن پیداست، Domain مغز و پیکره اصلی برنامه است و برنامه با تکیه بر Domain ساخته میشود.
در این معماری، ارزش تکنولوژی هایی مثل TDD بیش از پیش مشخص میشود. چرا که در DDD ابتدا Domain ساخته شده و بعد سایر لایه ها به آن الحاق میشوند. بنابراین با استفاده از TDD ما میتوانیم Domain را به طور مستقل و ایزوله، ساخته و تست کنیم.

برای روشن تر شدن مقاله، یک بار جریان یا Flow کار را مرور میکنیم.
فرض کنید در دیتابیس جدولی به نام Student داریم که یک سطر دارد.
در DDD و در لایه Data Layer ابتدا این سطر خوانده شده و در یک Entity Model به نام StudentEntityModel قرار میگیرد. این StudentEntityModel به لایه Domain پاس داده میشود. Domain با استفاده از Domain Serivice هایش، StudentEntityModel را به StudentDomainModel تبدیل میکند. StudentDomainModel کلاسی است که در سرتاسر لایه Domain استفاده میشود و عملیات بر روی آن انجام میشود. بعد از این مرحله، Domain ما StudentDomainModel را به لایه View یا UI پاس میدهد. در این لایه، با استفاده از FrontEnd Service موجود در لایه View، کلاس StudentDomainModel به یک StudentViewModel تبدیل میشود تا در UI نمایش داده شود.

این مطلب خلاصه ای کلی در رابطه با Domain Driven Design بود. طبیعتا مبحث Domain Driven Design بسیار گسترده تر از یک مقاله است. بنابراین، به مرور مقالاتی را در این باره، منتشر خواهیم کرد.

منبع انگلیسی




کلمات کلیدی : DDD

نظر بدهید

2 دیدگاه برای “تفاوت های انواع مدل در Domain Driven Design

  • احمد ایرانپور گفته
    19 فوریه 18

    با درود
    فکر میکنم انتیتی فریم ورک خیلی خیلی کاربردی هست .حداقل برای من اینطور بوده .مطمئنا آموزشش خالی از لطف نیست.اگه ممکنه بزارید

  • احسان گفته
    19 فوریه 18

    با تشکر از زحمات شما