Subdomain Açmak Ürün Stratejisi Değildir

Subdomain açmak kolay.

tool.domain.com labs.domain.com app.domain.com

Bir anda sistem düzenli görünür.

Ama URL düzeni product strategy değildir.

Yanlış sınırları subdomain’lere bölerseniz ürün mimarisini çözmezsiniz. Sadece karmaşıklığı DNS’e taşırsınız.

Subdomain’in gerçekten çözdüğü şeyler

Subdomain bazı durumlarda çok mantıklıdır.

Ayrı runtime. Ayrı deployment. Ayrı security boundary. Ayrı app shell. Ayrı authentication context. Ayrı ürün girişi. Ayrı caching veya routing ihtiyacı.

Bunlar gerçek teknik gerekçelerdir.

Ama “burası farklı görünsün” tek başına yeterli değil.

Kullanıcı açısından ayrı mı?

Ben önce sistem haritasını kullanıcı açısından okurum.

Kullanıcı ahmetcanal.coma geldiğinde kişi, kanıt, services ve projects bağlamını görüyor.

Bağımsız bir araç ise kullanıcının “Ahmet hakkında bilgi alma” işinden farklı bir işi olabilir.

Örneğin bir technical audit surface kullanıcının URL girip gözlem, evidence, risk ve priority çıktısı almasını sağlıyorsa bu kendi ürün döngüsüne yaklaşır.

Ama mevcut site içeriğini farklı bir skin ile sunan yüzey bağımsız ürün değildir.

URL’den önce responsibility map

Yeni subdomain kararı vermeden önce şu responsibility map’i çıkarırım:

• Bu yüzeyin sahibi kim?
• Hangi canonical data’yı kullanıyor?
• Auth var mı?
• Hangi deploy pipeline’a bağlı?
• Analytics nerede?
• Hangi domain entity’lerini kullanıyor?
• Hangi linkler canonical?
• SEO açısından duplicate surface yaratıyor mu?
• Kullanıcı geri döndüğünde hangi sisteme dönüyor?

Bu harita çıkmıyorsa subdomain mimariyi netleştirmek yerine gizleyebilir.

808 OS neden iyi bir karşı örnek?

808 OS’un değeri “ayrı dashboard” olmasından gelmiyor.

Projects, marketing, analytics, revenue ve operational signal gibi dağınık context’leri tek decision surface’e bağlamasından geliyor.

Yani ürün sınırını URL değil, decision model belirliyor.

Bu önemli.

Çünkü bir control center’ı ayrı subdomain’e koymak kolaydır. Onu gerçekten control center yapan şey, hangi signal’in hangi decision’a dönüştüğüdür.

Subdomain maliyetleri görünmez başlar

Yeni subdomain’in maliyeti ilk gün düşüktür.

Sonra şunlar gelir:

• canonical/hreflang yönetimi,
• sitemap,
• robots,
• OG metadata,
• cross-domain analytics,
• auth/cookie davranışı,
• navigation consistency,
• shared design tokens,
• deploy doğrulama,
• accessibility regression,
• broken external links.

Teknik izolasyon istiyorsanız bunlar kabul edilebilir maliyetlerdir.

Sadece görsel ayrım istiyorsanız pahalı olabilir.

Benim karar kuralım

Yeni bir ahmetcanal.com subdomain’i ancak şu üç şart birlikte varsa mantıklı:

Bağımsız değer: Kullanıcı doğrudan o yüzeye gelip işini tamamlayabiliyor.

Bağımsız sistem davranışı: Kendi flow, state veya runtime gereksinimi var.

Ekosistem bağlantısı: Ana marka ile ilişkisi açık; kopuk mikro-site değil.

Bunlardan biri yoksa önce ana sistem içinde çözmeyi tercih ederim.

Sonuç

URL ağacı mimari diyagram değildir.

Subdomain doğru kullanıldığında güçlü bir boundary aracıdır.

Yanlış kullanıldığında ise her yeni fikir için yeni bir bakım yüzeyi açar.

Önce ürün sınırını kurarım.

Sonra DNS onun sonucunu yansıtır.