Domain-Driven Design (DDD) ile Node.js Uygulamaları: İş Odaklı ve Sağlam Sistemler İnşa Edin
Yazılım dünyasında, uygulamalar büyüdükçe ve iş gereksinimleri karmaşıklaştıkça, kod tabanını yönetmek, değiştirmek ve ölçeklendirmek giderek zorlaşır. Özellikle iş domaininin derinlemesine anlaşılması gereken, zengin ve sürekli değişen iş kurallarına sahip projelerde, sadece teknik odaklı yaklaşımlar yetersiz kalabilir. Benim geliştirme tecrübelerimde, bu tür senaryolarda Domain-Driven Design (DDD) prensiplerini uygulamanın, yazılımın iş değerini artırma, kodun sürdürülebilirliğini sağlama ve ekip içi iletişimi güçlendirme konularında kritik bir rol oynadığını defalarca gördüm. Node.js'in esnekliği ve JavaScript'in dinamik yapısı, DDD'yi uygulamak için verimli bir zemin sunar.
Bu yazıda, Node.js tabanlı uygulamalarınızda Domain-Driven Design'ın (DDD) temel kavramlarını, stratejik ve taktiksel desenlerini inceleyecek, pratik örneklerle bu yaklaşımları nasıl entegre edebileceğinizi göstereceğim. Amacımız, sadece çalışan değil, aynı zamanda iş dünyasındaki karşılığını doğru yansıtan, bakımı kolay ve ölçeklenebilir sistemler inşa etmek.
Domain-Driven Design (DDD) Nedir ve Neden Önemlidir?
Domain-Driven Design (DDD), karmaşık iş alanlarındaki (domain) yazılımın geliştirilmesine yönelik bir yaklaşımdır. Temelinde, yazılımın çekirdeğini iş domaini ve onun mantığı üzerine kurma fikri yatar. Bu, domain uzmanları (iş birimleri) ve geliştiriciler arasında sürekli ve etkili bir işbirliğini teşvik eder. DDD, sadece kod yazmak yerine, işin nasıl çalıştığını derinlemesine anlamaya ve bu anlayışı yazılım tasarımına yansıtmaya odaklanır.
DDD'nin Temel Avantajları
- İş Odaklılık: Yazılımın iş gereksinimlerini tam olarak karşılamasını sağlar ve iş değeri yaratmaya odaklanır.
- Sürdürülebilirlik: Kod tabanı, iş domainindeki değişikliklere daha kolay adapte olabilir, bu da uzun vadede bakım maliyetlerini düşürür.
- Okunabilirlik ve Anlaşılabilirlik: Domain mantığının kodda açıkça temsil edilmesi, yeni geliştiricilerin projeye adaptasyonunu hızlandırır.
- Gelişmiş İletişim: Domain uzmanları ve geliştiriciler arasında "Ubiquitous Language" (Evrensel Dil) kullanarak ortak bir anlayış oluşturur.
Stratejik DDD: Büyük Resme Odaklanmak
DDD, bir projenin genel mimarisini ve farklı iş alanlarının nasıl ayrılacağını belirleyen stratejik tasarım kavramlarıyla başlar.
1. Bounded Contexts (Sınırlı Bağlamlar)
Karmaşık sistemler genellikle birden fazla iş alanını içerir. Bounded Context, belirli bir domain modelinin tanımlandığı ve uygulandığı bir mantıksal sınırdır. Bu sınırlar içinde, terimlerin ve kavramların anlamı sabittir. Örneğin, bir e-ticaret uygulamasında "Kullanıcı Yönetimi", "Sipariş Yönetimi" ve "Ürün Kataloğu" farklı Bounded Context'ler olabilir. Her bağlamın kendi domain modeli, kendi "Ubiquitous Language"ı ve hatta kendi veritabanı olabilir. Bu yaklaşım, mikroservis mimarisinin temelini oluşturur; her mikroservis genellikle bir Bounded Context'e karşılık gelir.
2. Ubiquitous Language (Evrensel Dil)
Domain uzmanları ve geliştiriciler arasındaki ortak, açık ve tutarlı dildir. Bu dil, hem toplantılarda hem de kodda kullanılır. Örneğin, bir e-ticaret sisteminde "Sepet", "Ürün" veya "Sipariş" kelimeleri herkes için aynı anlama gelmelidir. Bu, yanlış anlamaları en aza indirir ve iş kurallarının doğru bir şekilde kodlanmasını sağlar.
3. Context Mapping (Bağlam Haritalama)
Farklı Bounded Context'ler arasında nasıl etkileşim kurulduğunu tanımlar. Örneğin, "Sipariş Yönetimi" bağlamı, "Ürün Kataloğu" bağlamından ürün bilgilerini alabilir. Bu etkileşimler için farklı desenler (Open Host Service, Shared Kernel, Customer/Supplier gibi) mevcuttur. Mikroservisler arası iletişim stratejileri de burada kritik bir rol oynar. Mesaj kuyrukları gibi asenkron iletişim mekanizmaları, Bounded Context'ler arasında bağımsızlığı artırabilir.
Taktiksel DDD: Detaylı Tasarım ve Uygulama
Stratejik tasarımın ardından, her Bounded Context içinde domain modelinin nasıl inşa edileceğini belirleyen taktiksel desenlere geçilir.
1. Entities (Varlıklar)
Bir Entity, bir domain içindeki bir nesnenin kimliğini ve yaşam döngüsünü temsil eder. Örneğin, bir `User` (Kullanıcı) veya bir `Product` (Ürün) birer Entity'dir. Kimlikleri (genellikle bir ID ile) ve zaman içindeki durum değişiklikleri önemlidir. İki Entity, nitelikleri farklı olsa bile aynı ID'ye sahipse aynı Entity'dir. Niteliklerinden çok kimlikleri önemlidir.
2. Value Objects (Değer Nesneleri)
Bir Value Object, bir özelliğin veya özelliğin niteliklerinin birleşimidir, ancak bir kimliği yoktur. Örneğin, bir `Address` (Adres) veya bir `Money` (Para Birimi) birer Value Object olabilir. Bunlar değişmez (immutable) olmalıdır; eğer değer değişirse, yeni bir Value Object örneği oluşturulur. İki Value Object, tüm nitelikleri aynıysa aynı kabul edilir.
3. Aggregates (Topluluklar)
Bir Aggregate, bir veya daha fazla Entity ve Value Object'in mantıksal bir kümesidir ve bu küme bir bütün olarak ele alınır. Her Aggregate'in bir Aggregate Root'u (Topluluk Kökü) vardır. Tüm dış erişim ve değişiklikler, Aggregate Root üzerinden yapılmalıdır. Bu, Aggregate içindeki nesneler arasındaki tutarlılığı sağlar. Örneğin, bir `Order` (Sipariş) Aggregate'i, `Order` Entity'si ve buna bağlı `LineItem` (Sipariş Kalemi) Value Object'lerini içerebilir. `Order` Entity'si burada Aggregate Root'tur.
4. Domain Services (Etki Alanı Servisleri)
Bir operasyonun birden fazla Entity veya Value Object'i ilgilendirmesi ve doğal olarak tek bir Entity'ye ait olmaması durumunda Domain Services kullanılır. Örneğin, iki farklı para birimini dönüştürme işlemi bir `CurrencyConverter` Domain Service'i olabilir.
5. Repositories (Depolar)
Repositoryler, Aggregate Root'ların kalıcı depolama mekanizmasına erişimini sağlayan bir soyutlama katmanıdır. Doğrudan veritabanı işlemleri yerine, domain modelinin ihtiyaç duyduğu Aggregate Root'ları bulma, kaydetme ve silme gibi işlemleri kapsar. Bu, domain katmanını veritabanı detaylarından ayırarak test edilebilirliği ve esnekliği artırır. Bu konu hakkında daha derin bilgi için Node.js ve MongoDB'de Repository Deseni yazımı inceleyebilirsiniz.
6. Domain Events (Etki Alanı Olayları)
Bir domain içindeki önemli durum değişikliklerini duyurmak için kullanılırlar. Örneğin, bir siparişin oluşturulması (`OrderCreated`), bir ürünün stokunun değişmesi (`ProductStockUpdated`). Domain Event'ler, sistemi daha gevşek bağlı hale getirir ve diğer Bounded Context'lerin veya uygulama katmanlarının bu olaylara tepki vermesini sağlar. Node.js ile Olay Güdümlü Mimari yazısında bahsettiğim prensiplerle uyumludur.
Node.js'te DDD Uygulaması: Basit Bir Örnek
Bir e-ticaret uygulaması düşünelim. `Order` Aggregate'ini ve ona bağlı kavramları Node.js ve TypeScript ile nasıl modelleyebileceğimize bakalım. TypeScript'in gücünden faydalanmak, özellikle karmaşık domain modellerinde tip güvenliğini artırır. Bu konuda daha fazla bilgi için TypeScript'in Gücü yazımı okuyabilirsiniz.
Proje Yapısı Önerisi
src/
├── domain/ (İş kuralları, Entities, Value Objects, Aggregates, Domain Services, Repositories için interfaceler)
│ ├── order/
│ │ ├── Order.ts (Aggregate Root)
│ │ ├── LineItem.ts (Value Object)
│ │ ├── IOrderRepository.ts (Repository interface)
│ │ └── OrderService.ts (Domain Service)
│ └── shared/
│ ├── UniqueEntityID.ts (Value Object for IDs)
│ └── Result.ts
├── application/ (Uygulama katmanı, Use Cases)
│ ├── useCases/
│ │ ├── createOrder/ (bir use case)
│ │ │ ├── CreateOrderUseCase.ts
│ │ │ └── CreateOrderDTO.ts
│ │ └── ...
├── infrastructure/ (Uygulama katmanı bağımlılıklarını yöneten dış katman)
│ ├── persistence/ (Veritabanı implementasyonları)
│ │ ├── mongodb/ (MongoDB specific)
│ │ │ ├── MongoDBOrderRepository.ts (IOrderRepository implementasyonu)
│ │ └── ...
│ └── web/ (API, Express.js implementasyonu)
│ ├── controllers/
│ │ ├── OrderController.ts
│ └── ...
├── index.ts (Uygulama bootstrap)
Basit Bir `Order` Aggregate ve `LineItem` Value Object Örneği
// src/domain/order/LineItem.ts
interface LineItemProps {
productId: string;
productName: string;
quantity: number;
price: number;
}
class LineItem {
private constructor(private props: LineItemProps) {}
public static create(props: LineItemProps): LineItem {
// Validasyonlar burada yapılabilir
if (props.quantity <= 0) throw new Error("Quantity must be positive.");
return new LineItem(props);
}
get productId(): string { return this.props.productId; }
get productName(): string { return this.props.productName; }
get quantity(): number { return this.props.quantity; }
get price(): number { return this.props.price; }
get total(): number { return this.props.quantity * this.props.price; }
public equals(vo?: LineItem): boolean {
if (vo === null || vo === undefined) return false;
return this.productId === vo.productId && this.price === vo.price;
}
}
// src/domain/order/Order.ts (Aggregate Root)
interface OrderProps {
customerId: string;
orderDate: Date;
status: 'pending' | 'shipped' | 'delivered' | 'cancelled';
lineItems: LineItem[];
totalAmount: number;
}
class Order {
private constructor(private props: OrderProps, public id: string) {
// id genellikle UniqueEntityID Value Object ile yönetilir
}
public static create(props: Omit<OrderProps, 'status' | 'orderDate' | 'totalAmount'>, id?: string): Order {
const defaultProps: OrderProps = {
...props,
orderDate: new Date(),
status: 'pending',
totalAmount: props.lineItems.reduce((acc, item) => acc + item.total, 0)
};
// Validasyonlar burada yapılabilir
if (defaultProps.lineItems.length === 0) throw new Error("Order must have line items.");
const orderId = id || 'new-order-id'; // Gerçek uygulamada UUID kullanılır
return new Order(defaultProps, orderId);
}
changeStatus(newStatus: 'shipped' | 'delivered' | 'cancelled'): void {
// Durum geçiş validasyonları
this.props.status = newStatus;
// Domain Event yayılabilir: OrderStatusChanged(this.id, newStatus)
}
// Getter'lar
get customerId(): string { return this.props.customerId; }
get status(): 'pending' | 'shipped' | 'delivered' | 'cancelled' { return this.props.status; }
// ... diğer getter'lar
// Domain olaylarını yayma veya Aggregate'e özgü davranışlar
}
// Basit Kullanım
const item1 = LineItem.create({ productId: 'p1', productName: 'Laptop', quantity: 1, price: 12000 });
const item2 = LineItem.create({ productId: 'p2', productName: 'Mouse', quantity: 2, price: 200 });
const order = Order.create({
customerId: 'c123',
lineItems: [item1, item2]
});
console.log(order.status); // pending
order.changeStatus('shipped');
console.log(order.status); // shipped
Repository Uygulaması
MongoDB kullanıyorsanız, `MongoDBOrderRepository` gibi bir implementasyon, `IOrderRepository` arayüzünü gerçekleştirecektir. Bu sayede domain katmanı, veritabanı detaylarından tamamen bağımsız kalır.
// src/domain/order/IOrderRepository.ts
interface IOrderRepository {
findById(id: string): Promise<Order | null>;
save(order: Order): Promise<void>;
// ... diğer CRUD operasyonları
}
// src/infrastructure/persistence/mongodb/MongoDBOrderRepository.ts
import { Collection } from 'mongodb'; // Ya da Mongoose modeli
class MongoDBOrderRepository implements IOrderRepository {
constructor(private collection: Collection<any>) {}
async findById(id: string): Promise<Order | null> {
const doc = await this.collection.findOne({ _id: id });
if (!doc) return null;
// MongoDB dokümanından Order Aggregate'ini yeniden oluştur
// Bu kısım karmaşık olabilir ve bir 'Mapper' deseni kullanılabilir.
return Order.create(doc as any, doc._id);
}
async save(order: Order): Promise<void> {
await this.collection.updateOne(
{ _id: order.id },
{ $set: { ...order.props, _id: order.id } }, // 'props' ve 'id'yi kaydet
{ upsert: true }
);
}
}
DDD'nin Node.js Uygulamalarına Faydaları
Daha İyi İş Anlayışı: İş domaini, kodun merkezine yerleştirildiğinden, yazılım iş gereksinimlerine daha iyi uyum sağlar.
Modülerlik ve Bağımsızlık: Bounded Context'ler sayesinde sistem daha modüler hale gelir. Domain katmanı dış framework'lerden bağımsızdır, bu da bağımlılık enjeksiyonu ile daha da güçlenir.
Test Edilebilirlik: Saf domain mantığı (Entities, Value Objects, Aggregates) dış bağımlılıklardan arınmış olduğu için çok daha kolay test edilebilir. Bu, uygulamanızın kalitesini artırmak için önemlidir; daha fazla bilgi için Node.js Uygulamalarında Güvenilir Test Stratejileri yazımı okuyabilirsiniz.
Ölçeklenebilirlik: İyi tanımlanmış Bounded Context'ler, mikroservislere dönüşebilir ve bağımsız olarak ölçeklenebilir.
Zorluklar ve Ne Zaman Kullanmalı?
DDD, her proje için uygun değildir. Küçük, CRUD odaklı uygulamalar için aşırı mühendislik olabilir ve başlangıçta öğrenme eğrisi yüksek olabilir. Ancak:
- Karmaşık iş domainlerine sahip, kritik iş uygulamaları geliştiriyorsanız.
- İş kurallarının sıklıkla değiştiği ve yazılımın bu değişikliklere kolayca adapte olması gereken projelerde.
- Birden fazla ekibin farklı iş alanları üzerinde çalıştığı büyük ölçekli sistemlerde (mikroservisler).
Bu senaryolarda DDD, uzun vadede projenize önemli değer katabilir.
Sonuç
Domain-Driven Design (DDD), Node.js ile modern uygulamalar geliştirirken iş mantığını merkeze alarak daha sağlam, esnek ve sürdürülebilir sistemler inşa etmenizi sağlayan güçlü bir yaklaşımdır. Bounded Context'lerden Aggregate'lere, Repository'lerden Domain Event'lere kadar DDD'nin sunduğu kavramlar, karmaşık domainleri anlamlandırmanıza ve bu anlayışı kod tabanına yansıtmanıza yardımcı olur.
Başlangıçta bazı zorlukları olsa da, doğru bağlamda uygulandığında, DDD ekibinizin iş ve teknik anlamda daha derin bir uyum içinde çalışmasını sağlar ve projenizin gelecekteki evrimine hazır olmasını temin eder. Unutmayın, DDD bir araç kutusudur; tüm araçları her zaman kullanmak zorunda değilsiniz, ancak hangi araçların ne zaman işe yarayacağını bilmek sizi iyi bir zanaatkar yapar.
Eğer aklınıza takılan sorular olursa veya bu konular hakkında daha fazla bilgi almak isterseniz, bana ismailyagci371@gmail.com adresinden veya sosyal medya kanallarından benimle (İsmail YAĞCI) iletişime geçebilirsiniz. Sağlıklı ve başarılı kodlamalar dilerim!
Orijinal yazı: https://ismailyagci.com/articles/domain-driven-design-ddd-ile-nodejs-uygulamalari-is-odakli-ve-saglam-sistemler-insa-edin
Yorumlar
Yorum Gönder