مائیکرو سروسز میں ڈومین سے چلنے والا ڈیزائن (DDD)

جب تنظیمیں یک سنگی فن تعمیر سے مائیکرو سروسز کی طرف منتقل ہوتی ہیں، تو انہیں ایک اہم، بلند و بالا سوال کا سامنا کرنا پڑتا ہے: ہم اپنی خدمات کی حدود کیسے متعین کرتے ہیں؟

نظریہ میں، مائیکرو سروسز کو ڈھیلے، ڈیکپلڈ یونٹس ہونے چاہئیں جو آزادانہ طور پر تیار، تعینات اور اسکیل کی جا سکیں۔ تاہم، عملی طور پر، بہت سی ٹیمیں ایک تقسیم شدہ یک سنگی—ایک ایسا نظام بناتی ہیں جہاں خدمات کو اتنی مضبوطی سے جوڑا جاتا ہے کہ ایک کاروباری تبدیلی کے لیے بیک وقت متعدد سروسز میں ترمیم اور تعیناتی کی ضرورت ہوتی ہے، نیٹ ورک میں تاخیر اور تعیناتی گرڈ لاک کو کم کرنا۔

اس خرابی سے بچنے کے لیے، سافٹ ویئر آرکیٹیکٹس ڈومین سے چلنے والے ڈیزائن (DDD) کا رخ کرتے ہیں۔ سب سے پہلے ایرک ایونز نے 2003 میں متعارف کرایا، DDD ایک سافٹ ویئر ڈویلپمنٹ طریقہ کار ہے جو کوڈ ڈھانچے کو ان پیچیدہ کاروباری ڈومینز کے ساتھ ترتیب دیتا ہے جن کی وہ نمائندگی کرتے ہیں۔

اس مضمون میں، ہم دریافت کریں گے کہ کس طرح DDD صاف، ڈیکپلڈ، اور انتہائی قابل انتظام مائیکرو سروسز کو ڈیزائن کرنے کے لیے اسٹریٹجک اور ٹیکٹیکل بلیو پرنٹس فراہم کرتا ہے۔

1. اسٹریٹجک بلیو پرنٹ: سروس باؤنڈریز تیار کرنا

DDD کو دو بنیادی مراحل میں تقسیم کیا گیا ہے: سٹریٹجک ڈیزائن اور ٹیکٹیکل ڈیزائن۔ اسٹریٹجک ڈیزائن کاروباری سیاق و سباق کی ماڈلنگ اور سروس کی حدود کی وضاحت کے بارے میں ہے۔ یہ فن تعمیر کا “میکرو” منظر پیش کرتا ہے۔

A. ہر جگہ زبان

ایک کاروبار کے اندر، مختلف محکمے ایک ہی الفاظ کو بالکل مختلف چیزوں کے معنی میں استعمال کرتے ہیں۔ مثال کے طور پر:

• سیلز ٹیم کے لیے، ایک “صارف” لیڈ یا ممکنہ گاہک ہے۔
• سیکیورٹی ٹیم کے لیے، ایک “صارف” لاگ ان اسناد کا ایک مجموعہ ہے۔
• شپنگ ٹیم کے لیے، ایک “صارف” ایک جسمانی وصول کنندہ کا پتہ ہے۔

“صارف” کے لیے ایک واحد، متحد ڈیٹا بیس ماڈل بنانے کی کوشش کرنا جو ہر کسی کو مطمئن کرتا ہے، اس کے نتیجے میں ایک بڑے، الجھے ہوئے کوڈبیس کا نتیجہ نکلتا ہے۔ DDD اسے ایک ہر جگہ زبان قائم کر کے حل کرتا ہے—ایک مشترکہ ذخیرہ الفاظ جو ایک مخصوص حد کے اندر کاروباری ڈومین کے ماہرین اور ڈویلپرز دونوں کے ذریعہ بیان اور استعمال کیا جاتا ہے۔

B. پابند سیاق و سباق

A باؤنڈڈ سیاق و سباق وہ واضح حد ہے جس کے اندر ڈومین ماڈل لاگو ہوتا ہے۔ حد کے اندر، ہر جگہ زبان میں تمام اصطلاحات کا ایک واحد، غیر واضح معنی ہوتا ہے۔

ایک واحد “صارف” ماڈل کے بجائے، ہم ان کے متعلقہ پابند سیاق و سباق کے اندر الگ الگ ماڈلز کی وضاحت کرتے ہیں:

• آرڈر سیاق و سباق میں، ہمارے پاس ایک Order ماڈل ہے جس میں کسٹمر کے رابطے کی معلومات شامل ہیں۔
• شناختی سیاق و سباق میں، ہمارے پاس ایک Credentials ماڈل ہے۔
• شپنگ سیاق و سباق میں، ہمارے پاس ایک DeliveryAddress ماڈل ہے۔

مائیکرو سروسز کا سنہری اصول: ایک مائیکرو سرویس سے براہ راست ایک پابند سیاق و سباق کا نقشہ۔

سسٹم کو باؤنڈڈ سیاق و سباق میں تقسیم کرکے، ہم اس بات کو یقینی بناتے ہیں کہ مائیکرو سروسز ڈھیلے طریقے سے جوڑے جائیں اور مختلف کاروباری صلاحیتوں کی نمائندگی کریں۔

C. سیاق و سباق کی نقشہ سازی: خدمات کیسے بات چیت کرتی ہیں۔

پابند سیاق و سباق تنہائی میں موجود نہیں ہیں۔ انہیں بات چیت کرنا چاہئے. ایک سیاق و سباق کا نقشہ سیاق و سباق کے درمیان تعلقات اور ترجمے کے طریقہ کار کی وضاحت کرتا ہے۔ کلیدی نمونوں میں شامل ہیں:

• مشترکہ کرنل: دو سیاق و سباق ڈومین ماڈل اور ڈیٹا بیس کے ایک چھوٹے سے ذیلی سیٹ کا اشتراک کرتے ہیں (عام طور پر مائیکرو سروسز میں جوڑے کی وجہ سے حوصلہ شکنی کی جاتی ہے)۔
• کسٹمر-سپلائر: ایک سیاق و سباق (سپلائر) کو دوسرے (کسٹمر) کو ڈیٹا فراہم کرنا چاہیے۔ فراہم کنندہ کو گاہک کے ساتھ ریلیز کے نظام الاوقات کو مربوط کرنا چاہیے۔
• اینٹی کرپشن لیئر (ACL): ایک ٹرانسلیشن لیئر جو بیرونی سسٹم سے آنے والے ڈیٹا کو کلائنٹ کے اندرونی ڈومین ماڈل میں ترجمہ کرتی ہے، بیرونی ماڈلز کو اندرونی فن تعمیر کو آلودہ کرنے سے روکتی ہے۔

2. ٹیکٹیکل بلیو پرنٹ: مائیکرو سروس کوڈ بیس کی تشکیل

ایک بار جب سٹریٹجک ڈیزائن کا استعمال کرتے ہوئے سروس کی حدود تیار ہو جاتی ہیں، تو Tactical Design ایک مائیکرو سروس کے اندر کوڈ کی ساخت کے لیے ڈیزائن پیٹرن کا ایک سیٹ فراہم کرتا ہے۔

A. ہستی اور قیمتی اشیاء

مائیکرو سروس کے اندر، ماڈلز کو دو قسموں میں تقسیم کیا گیا ہے:

1. ہستی: ایسی اشیاء جن کی ایک منفرد شناخت ہوتی ہے جو وقت کے ساتھ ساتھ برقرار رہتی ہے، چاہے ان کی صفات بدل جائیں۔ مثالوں میں Order یا Product شامل ہیں۔
2. ویلیو آبجیکٹ: وہ آبجیکٹ جن کی کوئی منفرد شناخت نہیں ہے اور ان کی مکمل تعریف ان کی صفات سے ہوتی ہے۔ وہ ناقابل تغیر ہیں۔ مثالوں میں ShippingAddress یا ProductDimensions شامل ہیں۔ اگر دو قدر والی اشیاء میں ایک جیسی صفات ہوں تو انہیں برابر سمجھا جاتا ہے۔

B. مجموعی اور مجموعی جڑیں۔

ایک مجموعی متعلقہ اداروں اور ویلیو آبجیکٹ کا ایک کلسٹر ہے جسے ڈیٹا کی تبدیلیوں کے لیے ایک اکائی کے طور پر سمجھا جاتا ہے۔ ہر ایگریگیٹ کا ایک ایگریگیٹ روٹ ہوتا ہے، جو واحد انٹری پوائنٹ ہے جس کے ذریعے بیرونی اشیاء مجموعی کے ساتھ تعامل کر سکتی ہیں۔ جڑ اس بات کو یقینی بناتی ہے کہ تمام کاروباری تبدیلیاں (قواعد) نافذ ہیں۔

مثال کے طور پر، اوپر دیے گئے خاکے میں:

• آرڈر سروس میں، Order مجموعی جڑ ہے۔ اس میں OrderItem (اینٹی) اور ShippingAddress (ویلیو آبجیکٹ) شامل ہیں۔ بیرونی خدمات براہ راست OrderItem میں ترمیم نہیں کر سکتیں۔ انہیں Order روٹ (جیسے order.AddItem()) پر ایک طریقہ کو کال کرنا چاہئے، جو اس بات کی توثیق کرتا ہے کہ آرڈر پہلے سے بھیج دیا نہیں گیا ہے۔

C. ڈومین ایونٹس

ایک ڈومین ایونٹ کچھ ایسا ہوتا ہے جو اس ڈومین میں ہوا جس کا کاروباری ماہرین خیال رکھتے ہیں۔ اس کا استعمال باؤنڈڈ سیاق و سباق میں تبدیلیوں کو متضاد طور پر بات چیت کرنے کے لیے کیا جاتا ہے۔ جب ایک مجموعی کمانڈ پر عمل کرتا ہے، تو یہ ایک ڈومین ایونٹ شائع کرتا ہے (جیسے، OrderCreated)۔ دیگر سروسز اس ایونٹ کو سنتی ہیں اور اس کے مطابق اپنی حالت کو اپ ڈیٹ کرتی ہیں، مطابقت پذیر API انحصار کے بغیر حتمی مستقل مزاجی کو یقینی بناتی ہیں۔

3. ایک ٹھوس مثال: آرڈر سروس بمقابلہ انوینٹری سروس

آئیے آرڈر سروس کے لیے گو میں ٹیکٹیکل DDD کے ایک آسان نفاذ کو دیکھتے ہیں، یہ دکھاتے ہیں کہ مجموعی جڑ کس طرح کاروباری قواعد کو مربوط کرتی ہے۔

package domain

import (
	"errors"
	"time"
)

// Value Object (Immutable, identity-less)
type ShippingAddress struct {
	Street  string
	City    string
	ZipCode string
}

// Entity (Has identity, mutable)
type OrderItem struct {
	ProductID string
	Quantity  int
	Price     float64
}

// Aggregate Root (Enforces transactional boundaries)
type Order struct {
	ID        string
	Items     []OrderItem
	Address   ShippingAddress
	Status    string
	CreatedAt time.Time
}

// NewOrder creates a new Order Aggregate Root
func NewOrder(id string, address ShippingAddress) *Order {
	return &Order{
		ID:        id,
		Items:     []OrderItem{},
		Address:   address,
		Status:    "PENDING",
		CreatedAt: time.Now(),
	}
}

// AddItem enforces business rules before mutating state
func (o *Order) AddItem(productID string, qty int, price float64) error {
	if o.Status != "PENDING" {
		return errors.New("cannot add items to a finalized or cancelled order")
	}
	if qty <= 0 {
		return errors.New("quantity must be greater than zero")
	}
	
	o.Items = append(o.Items, OrderItem{
		ProductID: productID,
		Quantity:  qty,
		Price:     price,
	})
	return nil
}

جب آرڈر کامیابی کے ساتھ محفوظ ہو جاتا ہے، تو سروس میسج بروکر کو ایک ایونٹ شائع کرتی ہے:

{
  "event_id": "evt_98231",
  "event_type": "OrderCreated",
  "timestamp": "2026-06-26T00:15:00Z",
  "payload": {
    "order_id": "ord_5521",
    "items": [
      { "product_id": "prod_88", "quantity": 2 }
    ]
  }
}

انوینٹری سروس اس ایونٹ کو سنتی ہے، اس کی مقامی StockLevel ہستی کو اپ ڈیٹ کرتی ہے، اور بہاؤ کو متضاد طور پر مکمل کرتی ہے۔

4. مائیکرو سروسز میں اسٹریٹجک بمقابلہ ٹیکٹیکل DDD

نتیجہ: پہلے اسٹریٹجک DDD کے ساتھ شروع کریں۔

ڈومین سے چلنے والے ڈیزائن کو مائیکرو سروسز پر لاگو کرنا یہ یقینی بنانے کا ایک طاقتور طریقہ ہے کہ آپ کا فن تعمیر آپ کے کاروباری ڈھانچے سے میل کھاتا ہے۔ تاہم، ٹیمیں اکثر حکمت عملی کے نمونوں پر بہت زیادہ توجہ مرکوز کرنے کی غلطی کرتی ہیں (جیسے ریپوزٹری انٹرفیس اور ویلیو آبجیکٹ لکھنا) جبکہ اسٹریٹجک ڈیزائن کو نظر انداز کرتے ہیں۔

اگر آپ حدود کو درست نہیں کرتے ہیں تو، صاف حکمت عملی کوڈ کی کوئی مقدار آپ کے سسٹم کو تقسیم شدہ یک سنگی میں تبدیل ہونے سے نہیں بچائے گی۔ ہمیشہ اسٹریٹجک میپنگ کے ساتھ شروع کریں—اپنی ہر جگہ کی زبان کی وضاحت کریں، باؤنڈڈ سیاق و سباق میں گروپ لاجک بنائیں، مواصلات کے بہاؤ کا نقشہ بنائیں، اور اپنی مائیکرو سروسز کی حدود کو قدرتی طور پر ان تعریفوں سے ابھرنے دیں۔

غزنکس بلاگ پر مزید سافٹ ویئر آرکیٹیکچر، ڈیزائن پیٹرن، اور انجینئرنگ کی بصیرتیں دریافت کریں →