طراحی دامنه-محور چیست؟

طراحی دامنه-محور که اولین بار توسط اریک ایوانز (Eric Evans) در کتابی به همین نام در سال ۲۰۰۳ معرفی شد، یک فلسفه و مجموعه‌ای از الگوها برای طراحی نرم‌افزارهای پیچیده است. قلب تپنده DDD، مدل دامنه (Domain Model) است؛ مدلی غنی و پویا که مفاهیم، قوانین و فرآیندهای کسب‌وکار را در خود جای داده و به عنوان زبان مشترکی بین متخصصان کسب‌وکار (Domain Experts) و توسعه‌دهندگان عمل می‌کند.

برخلاف رویکردهای سنتی که اغلب با طراحی پایگاه داده آغاز می‌شوند (Data-Driven)، در DDD تمرکز اصلی بر درک عمیق دامنه و ساخت مدلی است که این درک را بازتاب دهد. این مدل، راهنمای اصلی برای طراحی و پیاده‌سازی سیستم خواهد بود.

چگونه یک معماری مبتنی بر DDD ایجاد کنیم؟

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

۱. طراحی استراتژیک (Strategic Design)

در این مرحله، تصویر بزرگ سیستم را ترسیم می‌کنیم. هدف، شناسایی مرزها و ارتباطات بین بخش‌های مختلف دامنه است. مفاهیم کلیدی در این بخش عبارتند از:

• زبان فراگیر (Ubiquitous Language): مهم‌ترین اصل در DDD، ایجاد یک زبان مشترک و بدون ابهام بین تمام اعضای تیم (فنی و غیرفنی) است. این زبان که از دل کسب‌وکار بیرون می‌آید، باید در تمام مکالمات، مستندات و حتی کد استفاده شود. برای مثال، اگر در یک سیستم فروش، به مشتری وفادار "مشتری طلایی" گفته می‌شود، در کد نیز باید از کلاس GoldenCustomer استفاده کرد.

• بافت محدود (Bounded Context): دامنه‌های بزرگ و پیچیده به بخش‌های کوچک‌تر و قابل مدیریت تقسیم می‌شوند که هر کدام "بافت محدود" نامیده می‌شوند. هر بافت محدود، مدل، داده‌ها و زبان فراگیر مخصوص به خود را دارد. برای مثال، در یک فروشگاه آنلاین، مفاهیمی مانند "محصول" در بافت "کاتالوگ" (Product Catalog) با مفهوم "محصول" در بافت "انبارداری" (Inventory) متفاوت است. در اولی، ویژگی‌هایی مثل نام، عکس و توضیحات مهم است و در دومی، تعداد موجودی و مکان فیزیکی.

• نقشه بافت (Context Map): این نقشه، روابط و نحوه تعامل بین بافت‌های محدود مختلف را به صورت بصری نمایش می‌دهد. این روابط می‌توانند به اشکال مختلفی مانند "همکاری" (Partnership)، "مشتری-تامین‌کننده" (Customer-Supplier) یا "لایه ضد فساد" (Anti-Corruption Layer) باشند.

۲. طراحی تاکتیکی (Tactical Design)

پس از مشخص شدن مرزها در طراحی استراتژیک، به سراغ جزئیات پیاده‌سازی مدل دامنه در هر بافت محدود می‌رویم. اینجاست که الگوهای سازنده (Building Blocks) DDD به کار می‌آیند:

• موجودیت (Entity): اشیائی در مدل که دارای هویت منحصربه‌فرد و یک چرخه عمر هستند. هویت یک موجودیت در طول زمان ثابت باقی می‌ماند، حتی اگر ویژگی‌های آن تغییر کند. برای مثال، یک Customer یک موجودیت است که با CustomerId شناسایی می‌شود.

• شیء ارزشی (Value Object): اشیائی که هویت مستقلی ندارند و تنها با مقادیر ویژگی‌هایشان تعریف می‌شوند. این اشیاء معمولاً تغییرناپذیر (Immutable) هستند. برای مثال، Address (شامل شهر، خیابان، پلاک) یک شیء ارزشی است. اگر آدرس تغییر کند، یک شیء Address جدید ساخته می‌شود.

• اگریگیت (Aggregate): یک خوشه از موجودیت‌ها و اشیاء ارزشی مرتبط که به عنوان یک واحد یکپارچه برای تغییرات داده در نظر گرفته می‌شوند. هر اگریگیت یک ریشه (Aggregate Root) دارد که تنها نقطه ورود برای دسترسی و تغییر در اعضای آن خوشه است. این الگو به حفظ ثبات و یکپارچگی (Consistency) قوانین کسب‌وکار کمک می‌کند. برای مثال، یک Order می‌تواند ریشه اگریگیتی باشد که شامل لیستی از OrderItem (موجودیت) و آدرس حمل (شیء ارزشی) است. هرگونه تغییر در سفارش، مانند افزودن یک آیتم، باید از طریق شیء Order انجام شود.

• سرویس‌های دامنه (Domain Services): گاهی اوقات، یک منطق یا عملیات کسب‌وکار به هیچ موجودیت یا شیء ارزشی خاصی تعلق ندارد. در این موارد، از سرویس‌های دامنه برای پیاده‌سازی این منطق‌ها استفاده می‌شود.

• مخزن (Repository): این الگو، وظیفه مدیریت ذخیره و بازیابی اگریگیت‌ها را بر عهده دارد و لایه دامنه را از جزئیات فنی نحوه ذخیره‌سازی (مانند پایگاه داده) جدا می‌کند.

مثالی از DDD در یک سیستم فروشگاه آنلاین

بیایید مفاهیم بالا را در یک مثال ساده از یک فروشگاه آنلاین به کار ببریم.

طراحی استراتژیک:

1. شناسایی دامنه‌ها: ما می‌توانیم دامنه‌های اصلی مانند مدیریت کاتالوگ، مدیریت سفارشات، مدیریت مشتریان و پرداخت را شناسایی کنیم.

2. تعریف بافت‌های محدود:

   • بافت کاتالوگ (Catalog Bounded Context): مسئول اطلاعات محصولات، دسته‌بندی‌ها و قیمت‌ها.

   • بافت سفارش (Ordering Bounded Context): مسئول فرآیند ثبت سفارش، محاسبه هزینه نهایی و پیگیری وضعیت.

   • بافت هویت‌سنجی (Identity & Access Bounded Context): مسئول مدیریت اطلاعات کاربران و احراز هویت.

3. زبان فراگیر: در بافت سفارش، مفاهیمی مانند Order، OrderItem، Customer و ShippingAddress با تعاریف دقیق و مشترک بین تیم فنی و فروش به کار می‌روند.

طراحی تاکتیکی (در بافت سفارش):

• اگریگیت Order:

  • ریشه اگریگیت: موجودیت Order با شناسه OrderId.

  • موجودیت‌های داخلی: لیستی از OrderItem. هر OrderItem هویت خود را دارد اما تنها از طریق Order قابل دسترسی است.

  • اشیاء ارزشی: ShippingAddress و Money (برای قیمت).

• قوانین کسب‌وکار: ریشه اگریگیت Order مسئول اعمال قوانینی مانند "یک سفارش نمی‌تواند بیش از ۱۰ آیتم داشته باشد" یا "پس از نهایی شدن سفارش، آیتمی به آن اضافه نمی‌شود" است.

• مخزن OrderRepository: این مخزن متدهایی مانند GetById(orderId) و Save(order) را فراهم می‌کند تا اگریگیت Order را بدون درگیر شدن با جزئیات SQL، ذخیره و بازیابی کند.

مقایسه DDD با سایر معماری‌ها

معماری لایه‌ای سنتی (N-Layered Architecture)

در معماری لایه‌ای کلاسیک، نرم‌افزار به لایه‌های فنی مانند لایه نمایش (UI)، لایه منطق کسب‌وکار (BLL) و لایه دسترسی به داده (DAL) تقسیم می‌شود.

• تمرکز: معماری لایه‌ای بر تفکیک فنی تمرکز دارد، در حالی که DDD بر تفکیک بر اساس مدل کسب‌وکار متمرکز است.

• جریان وابستگی: در معماری لایه‌ای، وابستگی‌ها معمولاً از بالا به پایین است (UI به BLL و BLL به DAL). اما در DDD، قلب سیستم، لایه دامنه است و تمام وابستگی‌ها به سمت آن است. لایه‌های دیگر مانند زیرساخت (Infrastructure) و اپلیکیشن (Application) به لایه دامنه وابسته هستند.

• پیچیدگی: برای پروژه‌های ساده CRUD-محور، معماری لایه‌ای کافی است. اما در سیستم‌های پیچیده با قوانین کسب‌وکار زیاد، مدل دامنه "کم‌خون" (Anemic Domain Model) در معماری لایه‌ای (که منطق در سرویس‌ها پراکنده است) مدیریت را دشوار می‌کند. DDD با قرار دادن منطق در کنار داده‌های مرتبط (در اگریگیت‌ها) به مدیریت این پیچیدگی کمک می‌کند.

معماری میکروسرویس (Microservices)

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

• رابطه: DDD و میکروسرویس نه تنها در تضاد نیستند، بلکه مکمل یکدیگر هستند. در واقع، DDD یکی از بهترین روش‌ها برای شناسایی مرزهای میکروسرویس‌هاست. هر بافت محدود (Bounded Context) در طراحی استراتژیک DDD، یک کاندیدای عالی برای تبدیل شدن به یک میکروسرویس است.

• استقلال: میکروسرویس‌ها بر استقلال در استقرار (Deployment) و فناوری تأکید دارند. DDD با تعریف مرزهای واضح از طریق بافت‌های محدود، به این استقلال کمک می‌کند و تضمین می‌کند که هر سرویس یک مسئولیت کسب‌وکار مشخص و منسجم دارد.

• هدف: هدف اصلی میکروسرویس، چابکی و مقیاس‌پذیری فنی است. هدف اصلی DDD، مدیریت پیچیدگی دامنه و همسویی با کسب‌وکار است. استفاده همزمان از این دو، به سیستمی منجر می‌شود که هم از نظر فنی قدرتمند و هم از نظر کسب‌وکار معنادار است.

مثال دختواره‌ای

در اینجا یک ساختار درختواره بر اساس معماری طراحی دامنه-محور (DDD) و لایه‌های مرتبط با آن ارائه می‌شود. این ساختار نشان می‌دهد که چگونه اجزای مختلف در کنار هم قرار می‌گیرند و قلب معماری، یعنی لایه دامنه، در مرکز قرار دارد.

معماری طراحی دامنه-محور (DDD)

  L-- لایه ارائه (Presentation Layer)
 |   --- کنترلرها (Controllers) / نقاط پایانی API
 |   --- نماها (Views) / کامپوننت‌های UI
 |   --- مدل‌های نمایش (View Models)

 L-- لایه اپلیکیشن (Application Layer)
 |   --- سرویس‌های اپلیکیشن (Application Services) / موارد استفاده (Use Cases)
 |   --- دستورات (Commands) و پرس‌و‌جوها (Queries) - (در صورت استفاده از الگوی CQRS)
 |   --- اشیاء انتقال داده (Data Transfer Objects - DTOs)

 L-- لایه دامنه (Domain Layer) - (قلب معماری)
 |   --- اگریگیت‌ها (Aggregates)
 |   |   ------ ریشه اگریگیت (Aggregate Root)
 |   |   ------ موجودیت‌ها (Entities)
 |   |   ------ اشیاء ارزشی (Value Objects)
 |   --- سرویس‌های دامنه (Domain Services)
 |   --- رویدادهای دامنه (Domain Events)
 |   --- رابط‌های مخزن (Repository Interfaces)
 |   --- قوانین کسب‌وکار (Business Rules)

 L-- لایه زیرساخت (Infrastructure Layer)
     --- پیاده‌سازی مخازن (Repository Implementations)
     |   ------ دسترسی به پایگاه داده (e.g., Entity Framework, Dapper)
     --- ارتباط با سرویس‌های خارجی (External Service Clients)
     --- سیستم‌های پیام‌رسان (Message Bus / Queues)
     --- لاگ‌گیری (Logging) و سایر نگرانی‌های مقطعی (Cross-Cutting Concerns)

توضیح ساختار:

• لایه ارائه (Presentation Layer): مسئول تعامل با کاربر یا سیستم‌های خارجی است. این لایه فقط با لایه اپلیکیشن در ارتباط است.

• لایه اپلیکیشن (Application Layer): وظیفه هماهنگی و ارکستراسیون را بر عهده دارد. این لایه موارد استفاده سیستم را پیاده‌سازی می‌کند، اما منطق اصلی کسب‌وکار در آن قرار ندارد. این لایه از لایه دامنه برای اجرای منطق کسب‌وکار استفاده می‌کند.

• لایه دامنه (Domain Layer): مهم‌ترین و مرکزی‌ترین بخش سیستم است. تمام مفاهیم، قوانین و منطق اصلی کسب‌وکار در این لایه قرار دارد و هیچ وابستگی به لایه‌های دیگر ندارد.

• لایه زیرساخت (Infrastructure Layer): شامل تمام جزئیات فنی و پیاده‌سازی است؛ مانند نحوه اتصال به پایگاه داده، ارسال ایمیل، یا ارتباط با یک API دیگر. این لایه، رابط‌های تعریف شده در لایه دامنه (مانند Repository Interfaces) را پیاده‌سازی می‌کند.

یک اشتباه رایج در پیاده‌سازی DDD: تله‌ی مدل دامنه کم‌خون (Anemic Domain Model)

یکی از بزرگترین چالش‌ها هنگام حرکت به سمت معماری DDD، ترک عادت‌های قدیمی است. بسیاری از توسعه‌دهندگان که به معماری‌های داده-محور (Data-Driven) عادت دارند، ناخواسته الگویی را پیاده‌سازی می‌کنند که اصول اصلی DDD را نقض می‌کند. این اشتباه، تزریق مستقیم ابزارهای دسترسی به داده مانند DbContext به لایه اپلیکیشن و نوشتن منطق کسب‌وکار در آنجاست.

بیایید با همان مثال فروشگاه آنلاین، این تله و راه صحیح خروج از آن را بررسی کنیم.

روش نادرست: وابستگی مستقیم به زیرساخت

در این رویکرد، سرویس اپلیکیشن برای انجام کار خود، مستقیماً به IDataBaseContext وابسته می‌شود.

نمونه کد (روش نادرست):

// In Application Layer
public class OrderService
{
    private readonly IMyDbContext _context;

    public OrderService(IMyDbContext context)
    {
        _context = context;
    }

    public async Task CreateOrder(CreateOrderDto dto)
    {
        // منطق کسب‌وکار در سرویس اپلیکیشن پراکنده شده است
        var order = new Order // 'Order' در اینجا فقط یک کیسه داده است
        {
            Id = new OrderId(Guid.NewGuid()),
            CustomerId = dto.CustomerId,
            Status = OrderStatus.Pending
            // ... سایر ویژگی‌ها
        };

        decimal totalPrice = 0;
        foreach (var item in dto.OrderItems)
        {
            // قوانین و محاسبات مستقیماً در اینجا انجام می‌شود
            var product = await _context.Products.FindAsync(item.ProductId);
            totalPrice += product.Price * item.Quantity;
            // ...
        }
        order.TotalPrice = totalPrice;

        await _context.Orders.AddAsync(order);
        await _context.SaveChangesAsync();
    }
}

مشکلات این رویکرد چیست؟

1. مدل دامنه کم‌خون (Anemic Domain Model): کلاس Order در اینجا هیچ رفتار یا منطقی ندارد. صرفاً مجموعه‌ای از propertyهاست و تمام هوش و قوانین مربوط به "سفارش" در خارج از آن و در OrderService قرار گرفته است.

2. نشت جزئیات زیرساخت: لایه اپلیکیشن حالا به صورت مستقیم با یک مفهوم پایگاه داده‌ای (DbContext) درگیر است. این یعنی شما نمی‌توانید به راحتی تکنولوژی پایگاه داده خود را تغییر دهید بدون اینکه لایه اپلیکیشن را دستکاری کنید.

3. تست‌پذیری دشوار: برای تست منطق ایجاد سفارش، شما مجبورید یک DbContext را شبیه‌سازی (Mock) کنید که بسیار پیچیده است. شما نمی‌توانید قوانین کسب‌وکار را به صورت مجزا از زیرساخت تست کنید.

4. پراکندگی منطق: اگر جای دیگری در سیستم نیاز به محاسبه قیمت کل سفارش داشته باشید، باید آن منطق را کپی کنید یا راهی برای استفاده مجدد از OrderService پیدا کنید که منجر به کدی پیچیده و شکننده می‌شود.

روش صحیح: استفاده از الگوی مخزن (Repository) و مدل دامنه غنی

در روش صحیح، ما با تعریف یک قرارداد (اینترفیس) در لایه دامنه، این لایه را از جزئیات پیاده‌سازی جدا می‌کنیم و منطق را به جایی که به آن تعلق دارد، یعنی خود مدل دامنه، بازمی‌گردانیم.

۱. غنی‌سازی مدل دامنه (Domain Layer):

ابتدا کلاس Order را هوشمند می‌کنیم. تمام منطق مربوط به خودش را کپسوله می‌کند.

۲. تعریف و پیاده‌سازی مخزن:

• اینترفیس در لایه دامنه:

public interface IOrderRepository { Task AddAsync(Order order); }

پیاده‌سازی در لایه زیرساخت:

public class OrderRepository : IOrderRepository
{
    private readonly MyDbContext _context;
    public OrderRepository(MyDbContext context) { _context = context; }

    public async Task AddAsync(Order order)
    {
        await _context.Orders.AddAsync(order);
        // Unit of Work pattern معمولاً در اینجا با SaveChanges مدیریت می‌شود
    }
}

۳. ارکستراسیون در لایه اپلیکیشن:

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

// In Application Layer
public class CreateOrderCommandHandler
{
    private readonly IOrderRepository _orderRepository;

    public CreateOrderCommandHandler(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public async Task Handle(CreateOrderCommand command)
    {
        // 1. از مدل دامنه بخواه یک اگریگیت بسازد
        var order = Order.Create(command.CustomerId);

        // 2. از خود اگریگیت بخواه که منطق را اجرا کند
        foreach (var item in command.OrderItems)
        {
            order.AddItem(item.ProductId, item.Quantity, item.Price);
        }

        // 3. از مخزن بخواه که نتیجه را ذخیره کند
        await _orderRepository.AddAsync(order);
    }
}

نتیجه‌گیری

معماری طراحی دامنه-محور یک تغییر پارادایم از "چگونه کد بنویسیم؟" به "چه کدی بنویسیم؟" است. این رویکرد، با قرار دادن کسب‌وکار در مرکز فرآیند توسعه نرم‌افزار، به ساخت سیستم‌هایی منجر می‌شود که نه تنها از نظر فنی پایدار و قابل نگهداری هستند، بلکه به طور واقعی مشکلات و نیازهای دنیای کسب‌وکار را حل می‌کنند. اگرچه DDD برای پروژه‌های ساده ممکن است هزینه‌بر و بیش از حد پیچیده باشد، اما برای نرم‌افزارهای بزرگ و پیچیده، یک ابزار استراتژیک و حیاتی برای موفقیت بلندمدت محسوب می‌شود.