Modüler, Ölçeklenebilir ve Sürdürülebilir Mimari Yaklaşım
Laravel, geliştirici deneyimi yüksek ve hızlı uygulama geliştirmeye olanak tanıyan bir framework olsa da; proje büyüdükçe klasik MVC yapısı tek başına yeterli olmamaya başlar. İş kurallarının controller’lara dağılması, model’lerin gereğinden fazla sorumluluk alması ve kodun zamanla okunamaz hale gelmesi, büyük Laravel projelerinde sıkça karşılaşılan problemler arasındadır.
Bu noktada Domain-Driven Design (DDD) yaklaşımı, Laravel projelerini daha modüler, anlaşılır ve uzun vadede sürdürülebilir hale getirmek için güçlü bir çözüm sunar. DDD, teknik detaylardan önce iş alanına (domain) odaklanmayı ve yazılım mimarisini bu doğrultuda şekillendirmeyi amaçlar.
Bu yazıda, Laravel projelerinde DDD yaklaşımını nasıl uygulayabileceğimizi, Entity, Aggregate Root, Repository Pattern ve Value Object kavramlarını, ayrıca domain bazlı klasör yapısı önerilerini gerçek kod örnekleriyle detaylı şekilde ele alacağız.
Domain-Driven Design (DDD) Nedir?
Domain-Driven Design, yazılım mimarisini iş kuralları (business rules) etrafında şekillendiren bir yaklaşımdır. DDD’nin temel hedefi, yazılım ile iş alanı arasındaki kopukluğu ortadan kaldırmaktır.
DDD’nin temel prensipleri şunlardır:
-
İş kuralları merkezde yer alır
-
Teknik detaylar ikinci plandadır
-
Kod, iş dünyasındaki kavramlarla birebir örtüşür
-
Domain, uygulamanın kalbidir
DDD’yi Laravel’de Neden Kullanmalıyız?
Laravel varsayılan olarak hızlı geliştirme odaklıdır. Ancak:
-
Büyük ekipler
-
Uzun ömürlü projeler
-
Karmaşık iş kuralları
-
SaaS ve enterprise uygulamalar
gibi senaryolarda DDD yaklaşımı ciddi avantaj sağlar.
Laravel + DDD’nin Avantajları
-
Daha okunabilir kod
-
Modüler yapı
-
Test edilebilirlik
-
Domain bağımsızlığı
-
Uzun vadede bakım kolaylığı
Laravel’de DDD Temel Kavramları
Entity Nedir?
Entity, kimliği olan ve yaşam döngüsü bulunan domain nesnesidir.
class User
{
public function __construct(
private UserId $id,
private Email $email
) {}
public function id(): UserId
{
return $this->id;
}
}
Value Object Nedir?
Value Object’ler kimliksizdir, değerleriyle anlam kazanır ve immutable yapıdadır.
class Email
{
public function __construct(private string $value)
{
if (! filter_var($value, FILTER_VALIDATE_EMAIL)) {
throw new InvalidArgumentException('Geçersiz email');
}
}
public function value(): string
{
return $this->value;
}
}
Aggregate ve Aggregate Root
Aggregate, birlikte tutarlı kalması gereken entity’ler bütünüdür.
Aggregate Root ise bu bütünün dış dünyaya açılan tek kapısıdır.
class Order
{
private array $items = [];
public function addItem(OrderItem $item): void
{
$this->items[] = $item;
}
}
Repository Pattern
Repository, domain katmanının veri kaynağıyla doğrudan temas etmesini engeller.
interface OrderRepository
{
public function save(Order $order): void;
public function findById(OrderId $id): ?Order;
}
class EloquentOrderRepository implements OrderRepository
{
public function save(Order $order): void
{
// Eloquent implementasyonu
}
}
Laravel’de DDD İçin Önerilen Klasör Yapısı
Domain Bazlı Modüler Yapı
app/
└── Domains/
└── Order/
├── Entities/
├── ValueObjects/
├── Repositories/
├── Services/
└── Aggregates/
Application Katmanı
app/
└── Application/
└── Order/
├── CreateOrder.php
└── CancelOrder.php
Infrastructure Katmanı
app/
└── Infrastructure/
└── Persistence/
└── Eloquent/
└── OrderRepository.php
Örnek DDD Akışı (Create Order Use Case)
class CreateOrder
{
public function __construct(
private OrderRepository $orders
) {}
public function execute(CreateOrderRequest $request): void
{
$order = Order::create(
new OrderId(),
new CustomerId($request->customerId)
);
$this->orders->save($order);
}
}
Controller DDD’de Nasıl Olmalı?
Controller sadece giriş noktasıdır.
class OrderController extends Controller
{
public function store(Request $request, CreateOrder $useCase)
{
$useCase->execute(
new CreateOrderRequest($request->all())
);
return response()->json(['status' => 'ok']);
}
}
Laravel Service Container ile Bağlama
$this->app->bind(
OrderRepository::class,
EloquentOrderRepository::class
);
DDD Her Proje İçin Uygun mu?
Hayır.
DDD Uygun Olan Projeler
-
Büyük ölçekli uygulamalar
-
Karmaşık iş kuralları
-
Uzun ömürlü projeler
-
SaaS ve enterprise sistemler
Uygun Olmayanlar
-
Küçük CRUD projeleri
-
MVP aşamasındaki ürünler
-
Kısa vadeli uygulamalar
SEO Açısından Bu Yapının Katkısı
DDD doğrudan SEO sağlamaz ancak:
-
Daha temiz kod
-
Daha az hata
-
Daha stabil uygulama
-
Daha iyi performans
dolaylı olarak SEO’yu olumlu etkiler.
Sonuç
Domain-Driven Design, Laravel projelerini sadece daha “düzenli” değil; aynı zamanda iş kurallarını doğru modelleyen, ölçeklenebilir ve bakımı kolay hale getirir. DDD’yi Laravel ile uygulamak başlangıçta ek efor gerektirse de, uzun vadede bu yaklaşımın sağladığı kazanımlar çok daha değerlidir.
