Tüm yazılar
19 · Mühendislik · 2026.03 · 5 dk

Aynı veri, dört kullanıcı: Türk Sanatı Platformu üzerine notlar

Türk Sanatı Platformu'nda ana merkez ve alt platformlar aynı ürünün içinde yaşıyor. Ziyaretçi, sanatçı, başvuru sahibi ve yönetici aynı veriye farklı ihtiyaçlarla yaklaşıyor; bu notta çok kiracılı bir yapıda bu farkları birlikte düşünmeyi anlatıyorum.

01Ana merkez ve alt platformlar

Türk Sanatı Platformu; sanatçı profillerini, eserleri, etkinlikleri, başvuruları ve editoryal içeriği bir ana merkez ve alt platformlar üzerinden sunan kurumsal bir sanat platformu. Alt platformlar farklı ülke veya yapılar için ayrılıyor. Kamuya açık web, kullanıcı alanı, yönetim paneli ve API birlikte ele alınıyor. Bu bir şirket projesi; ben kurumsal web uygulamasının geliştirme, entegrasyon ve teslim süreçlerinde sorumluluk aldım. Arayüz tarafında Next.js ve React, servis tarafında NestJS, veri tarafında Prisma ve PostgreSQL var; yığında Redis ve Tailwind CSS de yer alıyor.

Bu yapının ilk bakışta dikkat çeken yanı çok kiracılık. Ama bu projede beni daha çok düşündüren şey, aynı verinin karşısında duran farklı insanlar oldu.

02Dört bakış, tek veri

Bir sanatçı profilini düşünelim. İçerik ziyaretçisi için bu profil okunacak, gezinilecek bir sayfa. Sanatçı için kendi emeğini temsil eden ve güncel tutmak istediği bir alan. Başvuru sahibi için henüz bir sürecin içinde olan, sonucu belli olmayan bir kayıt. Yönetici için ise denetlenecek, yayına alınacak ya da düzeltilecek bir içerik. Veri aynı kalıyor, ama her biri o veriden farklı bir şey istiyor.

Bu farkı görmemek, genelde iki uçtan birine götürüyor bence. Ya her kullanıcı için ayrı bir veri kopyası ve ayrı kurallar oluşuyor, ki zamanla birbirinden kopuyorlar. Ya da herkese aynı ekran ve aynı alanlar gösteriliyor, ki bu da kimsenin işini tam görmüyor. Benim tercih ettiğim yaklaşım, verinin tek kalması ve farklılığın görünüm, yetki ve akış katmanında ifade edilmesi. Bu yaklaşımda yetkiler ve görünümler daha fazla düşünce istiyor, ama veri tutarlılığı korunuyor.

Veri tek kalabilir; ihtiyaçlar tek olmak zorunda değil.

03Çok kiracılık bir sınır meselesi

Ana merkez ve alt platformlar arasında içerik ve kullanıcı akışlarını ortak bir ürün içinde yönetirken, her platformun yerel bağlamını ve yönetim sorumluluklarını korumak gerekiyor. Çok kiracılığı ben öncelikle bir sınır meselesi olarak görüyorum: hangi veri hangi platforma ait, kim hangi platformda ne görebilir, ortak olan nerede başlayıp nerede bitiyor.

Bu sınırlar arayüzde kalırsa kırılgan olur. Bir platform bağlamının servis katmanında da, sorgularda da aynı şekilde taşınması gerekir. Böyle bir mimaride çok kiracılık, içerik yönetimi ve başvuru süreçleri ayrı ayrı çözülecek konular değil; aynı mimarinin parçaları. Birinde verilen karar, diğer ikisinin davranışını doğrudan etkiliyor.

04Yerel bağlam ve yönetim sorumluluğu

Alt platformların varlık sebebi zaten farklılık. Her yapı kendi içeriğini, kendi etkinliklerini ve kendi başvurularını yönetmek isteyebilir. Öte yandan ana merkezin bütüne bakabilmesi de gerekiyor. Bu iki ihtiyaç arasındaki dengeyi kurmak teknik olduğu kadar ürünle ilgili bir karar.

Yönetim panelinde bu denge en çok yetkilerde görünüyor. Bir yöneticinin yalnızca kendi platformunu mu, yoksa birden fazlasını mı gördüğü; bir içeriğin hangi platformda yayında olduğu; bir başvurunun hangi yapının değerlendirmesine düştüğü gibi sorular, ekran tasarımından önce cevaplanması gereken sorular. Bunlar cevaplanmadan yazılan bir panel, sonradan sürekli istisna eklenen bir panele dönüşür.

05Entegrasyon ve teslim tarafından bakmak

Bu projede rolüm geliştirmenin yanında entegrasyon ve teslim süreçlerini de kapsıyordu. Bu, ürüne biraz farklı bir açıdan bakmamı sağladı. Kamuya açık web, kullanıcı alanı, yönetim paneli ve API ayrı ayrı çalışıyor gibi görünse de, teslim anında hepsi aynı veri modeline ve aynı platform bağlamına dayanıyor. Bir katmanda yapılan küçük bir değişikliğin diğerlerinde nasıl karşılık bulduğunu teslim sırasında görmek, bu bütünlüğün ne kadar önemli olduğunu hatırlatıyor.

Kullanıcı deneyimi, yönetim akışları ve çok kiracılı servis yapısı birlikte çalışmak zorunda. Birini iyileştirirken diğerlerini gözden kaçırmamak, bence bu tür platformlarda en çok dikkat isteyen iş.

06Geriye kalan

Bu projeden aklımda kalan en net şey, bir veri modelini tasarlarken yalnızca varlıkları değil, o varlıklara bakan insanları da düşünmek gerektiği. İçerik ziyaretçisi, sanatçı, başvuru sahibi ve yönetici aynı kayda farklı sorularla geliyor. İyi bir yapı bu soruların hepsine cevap verebilmeli, ama bunu veriyi parçalamadan yapmalı. Bunun yolu bence teknik bir hile değil; her yeni ekran ya da akış eklendiğinde, o verinin diğer kullanıcılar için ne anlama geldiğini yeniden sormak.

İlgili yazılar
  1. 20İki dilde yayın: NoktaTR'de içerik, akış ve arayüz birlikteÜrün ve analiz2026.025 dk
  2. 21Klinik başvuru sisteminde formun arkasındaki süreçÜrün ve analiz2026.015 dk