Çok kiracılı bir SaaS platformu oluşturmak doğası gereği karmaşıktır. Sadece verileri değil; birden fazla müşteri arasında yalıtımı, ölçeklenebilirliği ve farklı iş yeteneklerini yönetiyorsunuz. Alan Odaklı Tasarım (DDD), bu karmaşıklığın üstesinden gelmek için gerekli stratejik çerçeveyi sağlar, ancak gerçek gücü Sınırlı Bağlamları tanımlamakta yatar. Çok kiracılı senaryolara doğru uygulandığında, Sınırlı Bağlamlar kiracınıza özgü mantığın yalıtılmış, ölçeklenebilir ve bakımı kolay kalmasını sağlar.
Neden Sınırlı Bağlamlar Çok Kiracılıkta Önemlidir
Çok kiracılı bir ortamda, "kiracı" kavramı tüm sisteme nüfuz eder. Ancak uygulamanızın her bölümünün kiracı bağlamını aynı şekilde işlemesi gerekmez. Sınırlı Bağlamlar, belirli iş kurallarının uygulandığı mantıksal sınırlar çizmenizi sağlar. Bu, kiracıya özgü mantığın çekirdek alan hizmetlerine sızdığı ve sistemin kırılgan ve ölçeklendirilmesi zor hale geldiği "Çamur Topu" mimarisini önler.
Buradaki temel ilke Bağlam Haritalaması'dır. Farklı bağlamların nasıl etkileşime girdiğini belirlemeniz gerekir. Örneğin, Faturalandırma Bağlamı, faturaları oluşturmak için kiracı kimliğini bilmek isteyebilir, ancak kiracının ürün kullanım detaylarını bilmek zorunda değildir. Bu ayrım, faturalandırma mantığındaki değişikliklerin kullanım izleme sistemini istemeden bozmasını engeller.
Bağlam Sınırlarını Belirleme
Sınırları tanımlamak için şunlara bakın:
- Dil Değişimleri: Terminoloji değiştiğinde (örneğin, "Sipariş"ten "Fatura"ya), muhtemelen yeni bir bağlamınız vardır.
- Veri Sahipliği: Belirli veriler için gerçeklik kaynağı kimdir? Kimlik Bağlamı kullanıcı kimlik bilgilerini, Abonman Bağlamı ise plan detaylarını sahiplenir.
- Yalıtım Gereksinimleri: Bu özellik bağımsız olarak ölçeklendirilmeli mi? Ödeme İşleme gibi yüksek işlem hacimli bağlamlar, Raporlama gibi düşük sıklıklı bağlamlardan yalıtılmalıdır.
Kod Uygulaması: Bağlam Yalıtımı
Pratikte, bu yalıtım kod yapısı ve entegrasyon desenleri aracılığıyla uygulanır. Çekirdek alanı dış kiracıya özgü değişikliklerden korumak için bir bozucu katman (ACL) kullanan aşağıdaki örneği göz önünde bulundurun:
public class TenantBillingAdapter implements BillingPort {
private final BillingService externalBillingService;
public void sendInvoice(String tenantId, Invoice invoice) {
// İç alan modelini dış faturalandırma modeline çevir
ExternalInvoice extInvoice = mapToExternal(invoice);
extInvoice.setTenantId(tenantId); // Kiracı bağlamını burada uygula
externalBillingService.process(extInvoice);
}
private ExternalInvoice mapToExternal(Invoice invoice) {
// Karmaşık eşleme mantığı bağlam sınırı içinde tutulur
return new ExternalInvoice(invoice.getId(), invoice.getTotal());
}
}
Kiracı kimliğinin alan mantığının derinliklerinde değil, sınırlarda nasıl uygulandığına dikkat edin. Bu, çekirdek alanın saf kalmasını ve çok kiracılı altyapıdan habersiz olmasını sağlar.
Bağlamlar Arasında Olay Tabanlı İletişim
Gevşek bağ için, bağlamlar arası durum değişikliklerini iletmek üzere alan olaylarını kullanın. Örneğin, bir Abonman Bağlamı bir kiracının planını yükselttiğinde bir olay yayınlar. Raporlama Bağlamı, abonman hizmetine doğrudan bir bağımlılık olmadan bu olayı dinleyebilir. Bu, her bağlamın nihai tutarlılık yoluyla veri tutarlılığını korurken bağımsız olarak evrilmesine olanak tanır.
Sonuç
Çok kiracılı SaaS'ta Stratejik DDD, mikro hizmetler için mikro hizmetler değildir. İş yetenekleri ve kiracı yalıtım gereksinimleri ile uyumlu net sınırlar çizmektir. Sınırlı Bağlamları dikkatlice tanımlayarak, sağlam, ölçeklenebilir ve bakımı kolay bir sistem oluşturursunuz; bu da SaaS platformunuzun müşterilerinizle birlikte büyümesini sağlar.