معماری Domain-Driven را بر روی بستر .Net تجربه کنید. بخش 2

[مهران موسوی]

در تاپیک قبل (http://barnamenevis.org/showthread.php?527173-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-Domain-Driven-%D8%B1%D8%A7-%D8%A8%D8%B1-%D8%B1%D9%88%DB%8C-%D8%A8%D8%B3%D8%AA%D8%B1-Net-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DA%A9%D9%86%DB%8C%D8%AF-%D8%A8%D8%AE%D8%B4-1) با کلیات رویکرد Domain-Driven و همچنین مفهوم Domain Model اشنا شدیم. در این مقاله به بررسی برخی مفاهیم جهت پیاده سازی Domain Model در نرم افزار می پردازیم.

Entity -

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

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


public interface IEntity<TEntity, TID>
{
TID Id { get; }

bool SameIdAs(TEntity entity);
}




public class Customer : IEntity<Customer, long>
{
public long Id { get; private set; }
public string Firstname { get; private set; }
public string Lastname { get; private set; }

public Customer(long id, string firstname, string lastname)
{
if (id <= 0)
throw new ArgumentException("Id");

Id = id;
Firstname = firstname;
Lastname = lastname;
}

public bool SameIdAs(Customer entity)
{
if (entity != null)
{
return entity.Id == this.Id;
}
return false;
}
.
.
.
}


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


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

- Value Object

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


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


public class Address
{
public string Street { get; private set; }
public string City { get; private set; }
public string State { get; private set; }
public string BlockNo { get; private set; }

public Address(string street, string city, string state, string blockNo)
{
Street = street;
City = city;
State = state;
BlockNo = blockNo;
}
}



public class Customer : IEntity<Customer, long>
{
public long Id { get; private set; }
public string Firstname { get; private set; }
public string Lastname { get; private set; }
public Address Address { get; private set; }

public Customer(long id, string firstname, string lastname, Address address)
{
if (id <= 0)
throw new ArgumentException("Id");

Id = id;
Firstname = firstname;
Lastname = lastname;
Address = address;
}
.
.
.
}


- 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 در ارتباط هستند. ( مانند سرویسی که مسئول ارتباط با وب سرویس ارسال پیامک است)

در این تاپیک با ۳ مفهوم Entity، Value Object و Service در DDD آشنا شدیم. در تاپیک های مرتبط بعد به بررسی مفاهیمی مانند Aggregate، AggregateRoot، Bounded Context و … می پردازیم.

شاد باشید

میتوانید من را در Linked-in دنبال کنید. از اینجا (http://linkedin.com/in/mehran-mousavi)

[MMR_1344]

از لطفی که میکنید ممنون
اما اگه همه رو در یک فولدر بزاری دسترسی به اون بهتر میشه
باز هم ممنون