آشنایی با مفاهیم Domain Driven Design

در این مقاله به بررسی برخی مفاهیم جهت پیاده سازی Domain Model در نرم افزار می پردازیم.

آشنایی با مفاهیم Domain Driven Design

در این مقاله به بررسی برخی مفاهیم جهت پیاده سازی Domain Model در نرم افزار می پردازیم.

Entity

Entity یا موجودیت به اشیایی گفته می شود که با ID (شناسه منحصر به فرد) تعریف و شناخته می شوند. برای مثال “مشتری” در سیستم فروش یک Entity می باشد. Entity در قالب یک کلاس با مشخصه ها (Attributes) و رفتارهای مختلف (Behaviors) پیاده سازی می شود. ویژگی ها و صفات مشتری ممکن است در طول عمر نرم افزار تغییر کند و ویرایش شود، اما ID آن ثابت است. ID می تواند مقداری واقعی و معنی دار مانند شماره شناسنامه مشتری و یا مقداری تخصیص شده توسط خود نرم افزار مانند کد اشتراک مشتری باشد. دو Entity مختلف می توانند ویژگی های یکسان داشته باشند بنابراین هر Entity باید متدی برای متمایز کردن خود از سایرین داشته باشد.

نمونه ای ساده از اینترفیس IEntity و موجودیت Custmer :

آموزش Domain Driven Design

آموزش Domain Driven Design

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

نکته : در مثال فوق ویژگی های موجودیت مشتری Encapsulate شده و قابلیت تغییر آنها از بیرون از کلاس وجود ندارد. این تکنیک باعث می شد تا مقادیر Property ها تنها توسط خود Entity تغییر یابد و Entity همیشه در وضعیت معتبر باشد. می توانید جهت تغییر Property ها متدی مانند Update بر روی کلاس مشتری تعریف نمایید.

Value Object

Value Object ها اشیایی هستند که تنها توسط ویژگی ها و مقادیرشان شناخته می شوند و برای سیستم اهمیت دارند. برای مثال “آدرس مشتری” می تواند در قالب یک Value Object طراحی شود. Value Object ها می توانند به Entity های مختلف تخصیص داده شوند و معمولا به صورت Immutable پیاده سازی می شوند.

برای مثال در کد زیر کلاس Address در قالب یک Value Object طراحی شده و در کلاس مشتری استفاده شده است :

آموزش Domain Driven Design

آموزش Domain Driven Design

Service

برخی عملیات ها در سیستم مربوط به یک شیء خاص نبوده و نمی توان آنها را در قالب یک شیء و یا رفتاری از یک شیء در نظر گرفت. این نوع عملیات ها در قالب یک Service نوشته شده و در قسمت های مختلف برنامه استفاده می شوند. Service ها به صورت Stateless طراحی می شوند، یعنی هیچگونه وضعیتی را در خود نگهداری نمی کنند. از آنجا که سرویس ها می توانند به ابزارهای زیر ساختی (مانند دیتابیس) و یا وب سرویس های Remote دسترسی داشته باشند، لذا Interface آنها در لایه ی Domain و پیاده سازی واقعی آنها در لایه های دیگر انجام می گیرد تا Domain به دیگر لایه ها وابسته نشود.

سرویس ها در DDD معمولا به ۳ دسته تقسیم می شوند :

Domain Service : سرویس هایی که مربوط به Business و لایه ی Domain نرم افزار می شوند. این سرویس ها معمولا پیاده سازی یک فرآیند، اعتبارسنجی یک فرآیند و یا بازیابی داده ها برای یک فرآیند (از طریق Repository ها) را برعهده دارند. Domain Service ها اغلب به داخل متدها و سازنده ی Entity ها Inject شده و استفاده می شوند.

Application Service : سرویس هایی که با کلاینت های بیرونی ارتباط دارند و پیام ها و دستورات (Commands) را به عملیات ها و پردازش های داخلی Domain تبدیل و اجرا می کنند.

Infrastructure Service : سرویس هایی که با منابع و وب سرویس های Remote در ارتباط هستند. ( مانند سرویسی که مسئول ارتباط با وب سرویس ارسال پیامک است)

آشنایی با مفاهیم Domain Driven Design طراحی و معماری نرم افزار دوره آموزشی معماری نرم افزارهای enterprise