Tek bir yapay zeka tarafından oluşturulan kod tabanının, paylaşılan mantık, tutarlı veri modelleri ve daha güvenli sürümlerle web uygulamaları, mobil uygulamalar ve API'leri nasıl güçlendirebileceğini keşfedin.

“Tek bir kod tabanı” nadiren her yerde çalışan tek bir UI demektir. Pratikte genellikle tek bir depo ve paylaşılan kurallar anlamına gelir—ayrı teslim yüzeyleri (web uygulaması, mobil uygulama, API) vardır ve hepsi aynı temel iş kararlarına dayanır.
İyi bir zihinsel model, asla anlaşmaması gereken parçaları paylaşmaktır:
Bu arada, tipik olarak UI katmanını bütünüyle paylaşmazsınız. Web ve mobil farklı navigasyon desenlerine, erişilebilirlik beklentilerine, performans kısıtlarına ve platform yeteneklerine sahiptir. UI paylaşmak bazı durumlarda kazanç sağlayabilir, ama “tek kod tabanı”nın tanımı bu değildir.
AI tarafından üretilen kod şunları dramatik şekilde hızlandırabilir:
Ama AI otomatik olarak tutarlı bir mimari üretmez. Net sınırlar olmadan, mantığı uygulamalar arasında çoğaltma, kaygıları karıştırma (UI doğrudan veritabanı kodunu çağırma) ve birden çok yerde “neredeyse aynı” doğrulamalar yaratma eğilimindedir. İvme, önce yapıyı tanımlamaktan—sonra tekrarlayan kısımları doldurmak için AI kullanmaktan gelir.
Tek bir AI-destekli kod tabanı başarılı olduğunda şunları sağlar:
Tek bir kod tabanı, neyi başarması gerektiği—ve neyi standartlaştırmaması gerektiği—açık olduğunda işe yarar. Web, mobil ve API farklı kitlelere ve kullanım desenlerine hizmet eder; aynı iş kurallarını paylaşsalar bile.
Çoğu üründe en az üç “ön kapı” vardır:
Amaç, davranışta tutarlılıktır (kurallar, izinler, hesaplamalar)—aynı deneyimler değil.
Yaygın bir hata modu “tek kod tabanı”nı “tek UI” gibi ele almaktır. Bu genellikle web-benzeri bir mobil uygulama veya mobil-benzeri bir web uygulaması üretir—her ikisi de sinir bozucu olur.
Bunun yerine şuna odaklanın:
Çevrimdışı modu: Mobil genellikle ağ olmadan okuma (ve bazen yazma) gerektirir. Bu, yerel depolama, eşitleme stratejileri, çakışma yönetimi ve net “gerçek kaynağın” kuralları anlamına gelir.
Performans: Web paket boyutu ve etkileşime geçme süresi önemser; mobil açılış zamanı ve ağ verimliliği; API ise gecikme ve throughput. Kod paylaşmak, her istemciye gereksiz modüller göndermek anlamına gelmemelidir.
Güvenlik ve uyumluluk: Kimlik doğrulama, yetkilendirme, denetim izleri, şifreleme ve veri saklama kuralları tüm yüzeylerde tutarlı olmalıdır. Düzenlemeli alanlarda çalışıyorsanız, kayıt, onam ve en az ayrıcalık gereksinimlerini baştan uygulayın—yamalar olarak değil.
Tek bir kod tabanı, net sorumluluklara sahip açık katmanlara organize edildiğinde en iyi şekilde çalışır. Bu yapı ayrıca AI tarafından üretilen kodun gözden geçirilmesini, test edilmesini ve bir kısmının diğerlerini bozmadan değiştirilmesini kolaylaştırır.
Çoğu ekibin üzerinde birleştiği temel şekil şöyledir:
Clients (Web / Mobile / Partners)
↓
API Layer
↓
Domain Layer
↓
Data Sources (DB / Cache / External APIs)
Ana fikir: kullanıcı arayüzleri ve taşıma detayları kenarlarda durur, iş kuralları merkezdedir.
“Paylaşılabilir çekirdek”, her yerde aynı şekilde davranması gereken her şeydir:
AI yeni özellikler ürettiğinde en iyi sonuç: domain kurallarını bir kez güncellersiniz ve her istemci otomatik olarak fayda sağlar.
Bazı kodları paylaşıma zorlamak maliyetli (ve riskli) olabilir:
Pratik kural: kullanıcı görebiliyorsa veya OS bozabiliyorsa, buna uygulama özgü kalmasına izin verin. İşle ilgili bir karar ise domain'de kalsın.
Paylaşılan domain katmanı, kod tabanının en “sıkıcı” hissettirmesi gereken kısmıdır: öngörülebilir, test edilebilir ve her yerde yeniden kullanılabilir. AI sisteminizi bu katmana dayandırmanız gereklidir—böylece web ekranları, mobil akışlar ve API endpoint'leri aynı kuralları yansıtır.
Ürününüzün temel kavramlarını entityler (zaman içinde kimliği olan şeyler, ör. Account, Order, Subscription) ve value objectler (değerleriyle tanımlanan şeyler, ör. Money, EmailAddress, DateRange) olarak tanımlayın. Davranışı ise use caseler (bazen application services denir) halinde yakalayın: “Sipariş oluştur”, “Abonelik iptal et”, “E-postayı değiştir”.
Bu yapı domain'i uzman olmayanlar için anlaşılır kılar: isimler neyin var olduğunu, fiiller sistemin ne yaptığını anlatır.
Domain mantığı tetiklendiğinin bir buton tıklaması, web form gönderimi veya API isteği olup olmadığını bilmemelidir. Pratikte bu şunları gerektirir:
AI kod ürettiğinde bu ayrımı kaybetmek kolaydır—modeller UI kaygılarıyla doluverir. Buna refaktör tetikleyicisi olarak bakın, tercih değil.
Doğrulama ürünlerin sıkça sürüklenme yaşadığı alandır: web bir şeyi izin verir, API reddeder veya mobil farklı doğrulama uygular. Doğrulamayı domain katmanına (veya paylaşılan bir doğrulama modülüne) koyun ki tüm yüzeyler aynı kuralları uygulasın.
Örnekler:
EmailAddress formatını bir kez doğrulayın, web/mobile/API yeniden kullansınMoney negatif toplamları engellesin, değerin nereden geldiğine bakılmaksızınBunu iyi yaparsanız, API katmanı çevirmen olur, web/mobile sunar—domain katmanı tek gerçek kaynak olarak kalır.
API katmanı sisteminizin “kamuya açık yüzü”dür—ve tek bir AI-destekli kod tabanında her şeyi sabitleyen kısım olmalıdır. Sözleşme netse, web uygulaması, mobil uygulama ve dahili servisler aynı kaynaktan üretilip doğrulanabilir.
Sözleşmeyi handler veya UI bağlamadan önce tanımlayın:
/users, /orders/{id}), öngörülebilir filtreleme ve sıralama./v1/... veya header-temelli) ve deprecasyon kurallarını dokümante edin.OpenAPI (veya GraphQL SDL) gibi bir şemayı kanonik yapı olarak kullanın. Bundan şunları üretin:
Bu AI tarafından üretilen kod için önemlidir: model çok kod üretebilir, ama şema tümünü hizalı tutar.
Birkaç vazgeçilmez kural koyun:
snake_case veya camelCase, ikisi birden olmasın; JSON ile üretilen tipler arasında eşleşsin.Idempotency-Key isteyin ve yeniden deneme davranışını tanımlayın.API sözleşmesini bir ürün gibi ele alın. Stabil olduğunda, diğer her şey üretmeyi, test etmeyi ve göndermeyi kolaylaştırır.
Web uygulaması paylaşılan iş mantığından büyük fayda sağlar—ve mantık UI kaygılarıyla dolaştığında zarar görür. Anahtar, paylaşılan domain katmanını “headless” bir motor olarak ele almaktır: kuralları, doğrulamayı ve iş akışlarını bilir, ama bileşenler, route'lar veya tarayıcı API'leri hakkında hiçbir şey bilmez.
Eğer SSR (server-side rendering) kullanıyorsanız, paylaşılan kod sunucuda çalışmaya uygun olmalıdır: doğrudan window, document veya tarayıcı depolama çağrısı olmamalıdır. Bu iyi bir zorlama oluşturur: tarayıcıya bağımlı davranışı ince bir web adaptör katmanına koyun.
CSR (client-side rendering) ile daha fazla özgürlüğünüz vardır, ama aynı disiplin yine fayda sağlar. Sadece CSR projeleri genellikle domain modüllerine UI kodu “yanlışlıkla” import eder—ta ki daha sonra SSR, edge rendering veya Node’da koşan testler eklenene kadar.
Pratik kural: paylaşılan modüller deterministik ve ortamdan bağımsız olmalı; cookie, localStorage veya URL ile ilgili her şey web katmanında olmalı.
Paylaşılan mantık domain durumunı (ör. sipariş toplamları, uygunluk, türetilmiş bayraklar) basit nesneler ve saf fonksiyonlar aracılığıyla dışa verebilir. Web uygulaması UI durumunu sahiplenmelidir: yükleme spinner'ları, form odaklanması, iyimser animasyonlar, modal görünürlüğü.
Bu, React/Vue gibi kütüphaneleri değiştirmeyi kolaylaştırır: iş kurallarını baştan yazmadan kütüphane değiştirilebilir.
Web katmanı şu işleri ele almalı:
localStorage, önbellekleme)Web uygulamasını, kullanıcı etkileşimlerini domain komutlarına çeviren ve domain sonuçlarını erişilebilir ekranlara çeviren bir adaptör olarak düşünün.
Mobil uygulama en çok paylaşılan domain katmanından fayda sağlar: fiyatlandırma, uygunluk, doğrulama ve iş akışları web ve API ile aynı davranmalıdır. Mobil UI, paylaşılan mantığın etrafında dokunma için optimize edilmiş, aralıklı bağlantıya ve cihaz özelliklerine uygun bir “kabuğun” görevini görür.
Paylaşılan iş mantığı olsa bile mobildeki desenler nadiren web ile birebir eşleşir:
Gerçek mobil kullanım bekliyorsanız, çevrimdışı varsayımı yapın:
Web, mobil ve API her biri kendi veri şekillerini ve güvenlik kurallarını icat ederse “tek kod tabanı” hızla bozulur. Çözüm, modelleri, kimlik doğrulamayı ve yetkilendirmeyi ürün kararları olarak tek yerde tanımlayıp bir kez kodlamaktır.
Modellerin yaşadığı bir yer seçin ve diğer her şeyi ondan türetin. Yaygın seçenekler:
Anahtar araç değil—tutarlılık. Eğer “OrderStatus” bir istemcide beş değere sahip, diğerinde altı değere sahipse, AI üretilen kod memnuniyetle derlenecek ama hatalar gönderecektir.
Kimlik doğrulama kullanıcı için aynı hissettirmeli ama mekanikler yüzeye göre farklı olmalı:
Tek bir akış tasarlayın: giriş → kısa ömürlü erişim → gerektiğinde yenileme → sunucu tarafı durumu geçersiz kılan çıkış. Mobilde sırları Keychain/Keystore gibi güvenli depolamada saklayın; webde httpOnly cookie tercih edin.
İzinler bir kez tanımlanmalı—tercihen iş kurallarına yakın bir yerde—ve sonra her yerde uygulanmalı.
canApproveInvoice(user, invoice)).Bu, “mobilde çalışıyor ama webde çalışmıyor” sürüklenmesini önler ve AI kod üretimine kimin ne yapabileceğine dair net, test edilebilir bir sözleşme verir.
Birleşik bir kod tabanı, build ve yayınlar öngörülebilir olduğunda birleşik kalır. Amaç: ekiplerin API, web ve mobil uygulamaları bağımsız şekilde yayınlayabilmesi—mantığı çatallamadan veya çevresel "özel durum"lar koymadan.
Tek bir repo, çoklu paket/uygulama içeren monorepo, tek kod tabanı için genellikle en iyi sonucu verir çünkü paylaşılan domain mantığı, API sözleşmeleri ve UI istemcileri birlikte evrilir. Atomik değişiklikler (tek PR bir sözleşmeyi ve tüm tüketicileri güncelleyebilir) ve daha basit refaktörler elde edersiniz.
Çoklu repo da birleşik çalışabilir ama koordinasyon maliyeti ödemeniz gerekir: paylaşılan paketlerin versiyonlaması, artefakt yayınlama ve kırıcı değişikliklerin senkronizasyonu. Örgütsel sınırlar, güvenlik kuralları veya ölçek nedeniyle monorepo pratik değilse çoklu repo seçin.
Her yüzeyi ayrı build hedefi olarak ele alın:
Build çıktılarının açık ve yeniden üretilebilir olmasını sağlayın (lockfile'lar, sabitlenmiş toolchain, deterministik buildler).
Tipik pipeline: lint → typecheck → unit test → sözleşme testleri → build → güvenlik taraması → deploy.
Konfigürasyonu koddan ayırın: environment değişkenleri ve gizli bilgiler CI/CD ve gizli yönetim sisteminde olsun, repoda değil. Aynı artefaktın environment'lar arasında yeniden dağıtılabilmesi için environment-spesifik overlay'ler (dev/stage/prod) kullanın—özellikle API ve web runtime için yeniden build etmeye gerek kalmadan.
Web, mobil ve API aynı kod tabanından çıktığında testler "bir kutucuk daha" olmaktan çıkar ve küçük bir değişikliğin üç ürünü birden kırmasını engelleyen mekanizma haline gelir. Amaç: sorunları en ucuz yerde tespit etmek ve riskli değişiklikleri kullanıcılara ulaşmadan önce engellemek.
Paylaşılan domain (iş mantığı) ile başlayın; en çok tekrarlanır ve altyapı olmadan test etmek en kolay olandır.
Bu yapı çoğu güveni paylaşılan mantıkta tutar, katmanların birleştiği yerdeki "kablolama" sorunlarını yakalar.
Monorepo içinde bile API derlenip kullanıcı deneyimini bozacak şekilde değişebilir. Sözleşme testleri bu sürüklenmeyi engeller.
İyi testler önemli, ama etraflarındaki kurallar da öyle:
Bu kapılarla AI destekli değişiklikler sık ama kırılgan olmadan yapılabilir.
AI, tek bir kod tabanını hızlandırabilir ama sadece hızlı bir junior mühendis gibi ele alındığında işe yarar: taslak üretir, okunmalı ve incelenmelidir. Amaç AI’yı hız için kullanmak; mimari, sözleşmeler ve uzun vadeli tutarlılık için insanları sorumlu tutmaktır.
AI’yı şu mekanik işleri üretmesi için kullanın:
İyi kural: AI tarafından üretilen kod okunarak veya test çalıştırılarak kolayca doğrulanabilecek şekilde üretilsin; iş anlamını sessizce değiştiren kod üretmesin.
AI çıktısı açık kurallarla sınırlandırılmalıdır, hislere bırakılmamalıdır. Bu kuralları kodun neresine koyduğunuz önemlidir:
AI kısa yol önersede sınırları ihlal ediyorsa, cevap "hayır" olmalı, derlense bile.
Risk sadece kötü kod değildir—izlenmeyen kararlardır. Bir iz audit izi bırakın:
AI en değerli olduğunda tekrarlanabilir: ekip neden bir şey üretildiğini görebilir, doğrulayabilir ve gerektikçe güvenle yeniden üretebilir.
Sistem düzeyinde AI-destekli geliştirmeyi benimsiyorsanız, en önemli “özellik” ham üretim hızı değil—çıktıların sözleşmeleriniz ve katmanlamanızla hizalı kalma yeteneğidir.
Örneğin, Koder.ai bir sohbet arayüzü üzerinden web, sunucu ve mobil uygulamalar oluşturmanıza yardımcı olan bir platformdur—aynı zamanda gerçek, dışa aktarılabilir kaynak kodu üreterek mimari sınırları korumanıza olanak verir. Bu tür araçlar, API sözleşmesi ve domain kurallarını tanımlayıp sonra React tabanlı web yüzeyleri, Go + PostgreSQL arka uçları ve Flutter mobil uygulamaları arasında tutarlılığı kaybetmeden hızlı yinelemeye imkan verir. Planlama modu, anlık görüntüler ve geri alma gibi özellikler de "üretilir → doğrulanır → terfi ettirilir" yayın disiplinine iyi uyar.
Genellikle bir depo ve bir dizi paylaşılan kural anlamına gelir; tek tip bir uygulama değil.
Uygulamada web, mobil ve API, ortak bir domain katmanı (iş kuralları, doğrulama, kullanım senaryoları) ve genellikle tek bir API sözleşmesi paylaşır; her platform kendi UI'sını ve platform entegrasyonlarını korur.
Asla uyuşmaması gerekenleri paylaşın:
UI bileşenleri, navigasyon ve cihaz/tarayıcı entegrasyonlarını platforma özgü tutun.
AI, iskelet ve tekrarlı işleri (CRUD, istemciler, testler) hızlandırır; fakat iyi sınırlar otomatik oluşmaz.
Kasıtsız bir mimari yoksa AI tarafından üretilen kod genellikle:
AI’yı iyi tanımlanmış katmanları doldurmak için kullanın, katmanları icat etmesi için değil.
Basit, güvenilir bir akış genellikle şöyledir:
Bu, iş kurallarını merkezileştirir ve test etmeyi ile AI ile eklemeyi kolaylaştırır.
Doğrulamayı tek bir yerde (domain veya paylaşılan doğrulama modülü) tutun ve her yerde yeniden kullanın.
Pratik örnekler:
EmailAddress formatını bir kez doğrulayın, web/mobile/API tarafından yeniden kullanınMoney negatif toplamları her durumda engellesinBöylece "web kabul ediyor, API reddediyor" sürüklenmesini önlersiniz.
OpenAPI (veya GraphQL SDL) gibi kanonik bir şema kullanın ve bundan üretin:
Ayrıca sözleşme testleri ekleyin ki şema ihlalleri CI'de başarısız olsun.
Çevrimdışı amaçlı tasarım, sadece "cache işe yarar umudu" değil:
Çevrimdışı depolama ve eşitleme mobil katmanda olsun; iş kuralları paylaşılan domain kodunda kalsın.
Kullanıcı için tek bir akış tasarlayın, yüzeylere uygun şekilde uygulayın:
Yetkilendirme kuralları merkezi olarak tanımlanmalı (ör. canApproveInvoice) ve ; UI sadece eylemleri gizlemek/devre dışı bırakmak için aynısını yansıtmalı.
Her yüzeyi ayrı bir build hedefi olarak ele alın, ortak paketleri tüketsinler:
CI/CD hattında: lint → typecheck → unit test → sözleşme testi → build → güvenlik taraması → deploy. Gizli bilgiler repoda değil, CI/CD’nin sekret yöneticisinde olsun.
AI’yı hızlı bir junior mühendis gibi kullanın: taslaklar için harika, doğrudan merge edilmemeli.
Koruyucular:
AI çıktısı sınırları ihlal ediyorsa, derlense bile reddedin.