Veritabanı Yapısı

Qapu veritabanı yapısı, tek bir ürünün ihtiyacına göre zamanla büyümüş bir tablo kümesi olarak değil; birden fazla IoT ürün hattını aynı omurga üzerinde taşıyabilecek platform veri modeli olarak ele alınır. Bu nedenle burada asıl mesele tablo sayısı değil, sorumlulukların doğru ayrılmasıdır. Hangi veri hangi bağlamda yaşar, hangi tablo ailesi hangi yaşam döngüsünü taşır ve hangi katman nerede başlar sorusu, yapının temelini oluşturur.

Qapu’nun veritabanı modeli katmanlıdır; çünkü platformun taşıdığı problemler de katmanlıdır. Kimlik ve yetki başka hızda değişir, cihaz ve altyapı başka doğruluk mantığı ister, telemetri başka hacimde akar, kural ve aksiyon başka türde durum yönetir, mesajlaşma ve finans gibi alanlar ise sistemin kullanıcı ve işletme yüzünü oluşturur. Bunların tek parça düşünülmesi kısa vadede kolay görünür; fakat büyüme başladığında hem geliştirme hem bakım maliyeti hızla kontrolden çıkar.

Bu yüzden veri modeli domain ailelerine ayrılır. Bu ayrım yalnız dokümantasyon düzeni için değil, sistemin bounded context sınırlarını net tutmak için yapılmıştır. Her tablo ailesi kendi bağlamında okunur, düzenlenir ve geliştirilir; ama hepsi aynı operasyon omurgasının parçasıdır.

Yüksek seviye veri omurgası

Qapu içindeki temel veri hareketi birkaç büyük blok etrafında döner. Kimlik ve yetki katmanı, kullanıcı ve erişim omurgasını taşır. Cihaz, altyapı ve IoT katmanı sahadaki fiziksel varlıkları ve onların haberleşme bağlamını tanımlar. Telemetri ve ölçüm katmanı ham veriyi kabul eder, normalize eder ve anlamlı ölçüm kayıtlarına dönüştürür. Kural ve aksiyon katmanı bu ölçümleri iş kurallarına ve sistem reaksiyonlarına bağlar. Mesajlaşma, finans, not ve log gibi uygulama katmanları ise bu operasyonun kullanıcıya, yönetime ve sistem gözlemlenebilirliğine bakan yüzlerini oluşturur.

Bu akış, veritabanının yalnız veri saklayan bir yapı olmadığını gösterir. Veri önce bağlama oturur, sonra işlenir, ardından karar ve aksiyon katmanına taşınır. Veritabanı yapısı da tam olarak bu yaşam döngüsünü yansıtacak şekilde bölünmüştür.

Domain sınıflandırması

Qapu içindeki tablo aileleri aynı veritabanında yaşasa da aynı seviyede görülmemelidir. Bazı alanlar doğrudan platform çekirdeğidir. Bazıları birden fazla ürün tarafından paylaşılabilen ortak servis katmanıdır. Bazıları ise ürün uzantısı veya uygulama yüzü niteliğindedir. Bu ayrımı baştan net koymak, ileride platform çekirdeğinin ürün ihtiyaçlarıyla şişmesini ve servis sınırlarının bulanıklaşmasını önler.

Core platform domains

Core alanlar, ürün değişse bile ayakta kalması gereken omurgadır. Kullanıcı ve yetki, cihaz ve detay, IoT altyapı, IoT iletişim, telemetri ve ölçüm çekirdeği, kural ve aksiyon ile log/audit aileleri bu sınıfa girer. Bunlar Qapu’nun gerçek platform omurgasını oluşturur. Bir ürünün yaşam döngüsünden bağımsız düşünülmeli, platform kararı olarak korunmalıdır.

Shared platform services

Mesajlaşma ve bildirim katmanı, adres ve konum yapısı ve bazı ortak sözlük tabloları çekirdek kadar sert değildir; ancak farklı ürünlerin ortak kullanabileceği servis alanlarıdır. Bu nedenle bunlar çekirdekten ayrı düşünülmeli, ama ürünlere özel geçici detay muamelesi de görmemelidir.

Product extension domains

Tarım, saha, arazi ve sulama bağlamı taşıyan tablolar ile bazı ölçüm uzantıları ürün kimliğine daha yakındır. Bunlar platform tarafından taşınabilir; fakat platformun temel tanımı bu alanlarla yapılmamalıdır. Qapu bu tür product extension alanlarını desteklemeli, ancak çekirdeğin sınırlarını bu alanlara göre yeniden şekillendirmemelidir.

Application surface domains

Finans, notlar ve kullanıcıya dönük bazı uygulama katmanları veri modelinin üst yüzünde yer alır. Bunlar platformla aynı veritabanında yaşasa bile çekirdek veri motoruyla aynı sınıfta düşünülmemelidir. Bu ayrım, ileride hangi alanın bağımsız servis veya modül haline gelebileceğini de daha erken görünür kılar.

Mimari disiplin

Bir tablo ailesi yeni eklenirken ilk soru şu olmalıdır: bu alan gerçekten Qapu çekirdeği mi, yoksa paylaşılan servis, ürün uzantısı ya da uygulama yüzü mü? Bu soru sorulmadan yapılan her ekleme, zamanla platformun sınırlarını belirsizleştirir.

Tablo detayları

Veri modelinin kolon, ilişki ve tablo bazlı detayları ayrı sayfalarda tutulur. Bu tercih, büyüyen veritabanı anlatısını tek bir dev dökümanda boğmak yerine domain aileleri halinde düzenli tutmak için yapılmıştır.

Tablo aileleri

Asagidaki sira, tables/*/index.mdx dosyalarindaki sidebar_position degerlerinden gelir:

Sira	Dizin	Baslik
1	`tables/kullanici-ve-yetki`	Kullanici ve Yetki Tablolari
2	`tables/mesajlasma-ve-bildirim`	Mesajlasma ve Bildirim Tablolari
3	`tables/adres-ve-konum`	Adres ve Konum Tablolari
4	`tables/sozluk`	Sozluk Tablolari
5	`tables/altyapi`	Altyapi Tablolari
6	`tables/cihaz-ve-detay`	Cihaz ve Detay Tablolari
7	`tables/log`	Log Tablolari
8	`tables/iot-altyapi`	IoT Altyapi Tablolari
9	`tables/iot-iletisim`	IoT Iletisim Tablolari
10	`tables/telemetri-ve-olcum`	Telemetri ve Olcum Tablolari
11	`tables/kural-ve-aksiyon`	Kural ve Aksiyon Tablolari
12	`tables/finans-uygulamasi`	Finans Uygulamasi Tablolari
13	`tables/not-uygulamasi`	Not Uygulamasi Tablolari

Tum detayli tablo listesi: Tablolar Detaylari

Alt dizin başlık haritası

Aşağıdaki yapı, tablo ailelerinin yalnız klasör olarak değil, sorumluluk alanı olarak nasıl ayrıldığını gösterir. Bu bölümün amacı her alt dizini tek tek yeniden yazmak değil; hangi başlığın hangi problem alanını tuttuğunu görünür kılmaktır.