Composable Architecture (Bilesik Mimari) Rehberi [2026]

Composable Architecture Nedir?

Composable architecture (bilesik mimari), yazilim sistemlerinin bagimsiz, degistirilebilir ve yeniden kullanilabilir bilesenlerden olusturuldugu bir mimari yaklasimdir. Gartner tarafindan 2020 yilinda kavramsallastirilan bu yaklasim, isletmelerin degisen pazar kosullarina hizla uyum saglamasini hedefler.

Geleneksel monolitik yapilardan farkli olarak composable architecture, her bir is yetenegini bagimsiz bir bilesene donusturur. Bu bilesenler API'ler araciligiyla iletisim kurar, bagimsiz olarak gelistirilir, test edilir ve devreye alinir. Sonuc olarak organizasyonlar, ihtiyac duydukca bilesenleri ekleyebilir, cikarabilir veya degistirebilir.

Bu yaklasimin temelinde uc ana prensip yer alir:

• Modulerlik: Her bilesem belirli bir is islevini yerine getirir ve diger bilesenlerden bagimsiz calisir.
• Otonomi: Bilesenler kendi yasam dongulerini yonetir; bir bilesenin guncellenmesi diger bilesenleri etkilemez.
• Orkestrasyon: Bilesenler arasindaki iletisim ve is akislari merkezi bir katman uzerinden yonetilir.

MACH Prensipleri

Composable architecture'in teknik altyapisini MACH prensipleri olusturur. MACH Alliance tarafindan tanimlanan bu dort temel ilke, modern dijital sistemlerin nasil insaa edilmesi gerektigini belirler.

Microservices (Mikro Hizmetler)

Her is islevi, bagimsiz olarak gelistirilen ve dagitilan kucuk hizmetler halinde tasarlanir. Mikro hizmetler kendi veritabanlarini yonetir, kendi teknoloji yiginlarini secebilir ve bagimsiz olarak olceklenebilir. Bir odeme hizmeti ile envanter hizmeti birbirinden habersiz calisir, ancak tanimli API kontratlar uzerinden iletisim kurar.

API-First (API Oncelikli)

Tum islevsellik, iyi tasarlanmis API'ler uzerinden sunulur. API-first yaklasiminda oncelikle API kontrati tasarlanir, ardindan uygulama gelistirilir. Bu sayede farkli ekipler paralel calisabilir ve frontend ile backend gelistirme surecleri birbirinden bagimsizlasir.

Cloud-Native (Bulut Yerel)

Uygulamalar bulut ortaminda calisacak sekilde tasarlanir. Konteynerler, sunucusuz islevler ve yonetilen hizmetler kullanilarak altyapi karmasikligi azaltilir. Otomatik olceklendirme, yuksek erisilebilirlik ve felaket kurtarma yetenekleri dogal olarak sistemin parcasi haline gelir.

Headless (Basiz)

Sunum katmani (frontend) ile is mantigi katmani (backend) birbirinden tamamen ayrilir. Bu ayrim sayesinde ayni backend API'leri uzerinden web sitesi, mobil uygulama, IoT cihazlari veya dijital kiosk gibi farkli kanallara icerik ve islevsellik sunulabilir.

Monolith, Microservices ve Composable Karsilastirmasi

Dogru mimari secimi, organizasyonun buyuklugu, teknik olgunlugu ve is hedeflerine baglidir. Asagidaki tablo, uc yaklasimin temel farklarini ortaya koyar.

Ozellik	Monolith	Microservices	Composable
Dagitim birimi	Tek buyuk uygulama	Bagimsiz hizmetler	Paketlenmis is yetenekleri (PBC)
Teknoloji esnekligi	Tek teknoloji yigini	Hizmet basina serbest	Bilesen basina serbest
Olceklendirme	Tum uygulama birlikte	Hizmet bazinda	Is yetenegi bazinda
Ekip yapisi	Buyuk, merkezi ekip	Hizmet odakli kucuk ekipler	Yetenek odakli ekipler
Degisiklik hizi	Yavas, riskli	Hizli, izole	Cok hizli, tak-cikar
Karmasiklik	Dusuk (baslangicta)	Yuksek (operasyonel)	Orta-yuksek (orkestrasyon)
Baslangic maliyeti	Dusuk	Orta	Yuksek
Uzun vadeli maliyet	Yuksek (teknik borc)	Orta	Dusuk-orta
Uygun oldugu durum	Kucuk ekipler, MVP	Olceklenen sistemler	Kurumsal dijital donusum

Monolitik yapilar kucuk ekipler ve erken asamadaki projeler icin hala gecerli bir secenektir. Ancak sistem buyudukce ve is gereksinimleri cresitlendikce, composable yaklasim belirgin avantajlar sunar.

Packaged Business Capabilities (PBC)

Composable architecture'in temel yapi tasi Packaged Business Capabilities yani paketlenmis is yetenekleridir. PBC kavrami, mikro hizmetlerin bir ust seviyesidir. Tek bir API endpoint'i degil, tam bir is yetenegini temsil eder.

Bir PBC su bilesenleri icerir:

• Veri: Kendi veritabani ve veri modeli
• Is mantigi: Is kurallarini uygulayan servisler
• API'ler: Dis dunyayla iletisim icin tanimli arayuzler
• Olaylar: Diger PBC'lerle asenkron iletisim icin olay yayinlama yetenegi

Ornegin bir "Siparis Yonetimi" PBC'si, siparis olusturma, siparis durumu takibi, siparis iptali ve iade sureclerini iceren butunlesik bir is yetenegidir. Icerisinde birden fazla mikro hizmet barindirir, ancak dis dunyaya tek bir PBC olarak sunulur.

Ornek PBC Yapilari

PBC	Icerik	Ornek Teknolojiler
Odeme Yonetimi	Odeme isleme, fatura, iade	Stripe, Adyen, ozel cozum
Urun Katalogu	Urun bilgileri, kategori, fiyat	Commercetools, ozel PIM
Icerik Yonetimi	Sayfa, blog, medya	Contentful, Strapi
Arama	Tam metin arama, filtreleme, oneri	Algolia, Elasticsearch
Kimlik Yonetimi	Kullanici kayit, giris, yetkilendirme	Auth0, Keycloak
Bildirim	E-posta, SMS, push notification	Twilio, ozel cozum

Composable Commerce ve Composable Enterprise

Composable Commerce

E-ticaret sektoru, composable architecture'in en yaygin uygulandigi alanlardan biridir. Composable commerce, geleneksel monolitik e-ticaret platformlarinin (Magento, SAP Commerce gibi) yerini alan bir yaklasimdir.

Composable commerce'de her e-ticaret islevi ayri bir best-of-breed cozumle karsilanir:

• Urun bilgi yonetimi icin ozel bir PIM sistemi
• Arama ve kesfetme icin Algolia veya benzer bir cozum
• Odeme isleme icin Stripe veya Adyen
• Icerik yonetimi icin headless CMS
• Siparis yonetimi icin ozel bir OMS

Bu bilesenlerin tumunu bir arada calismasi icin bir orkestrasyon katmani ve deneyim katmani (experience layer) gereklidir.

Composable Enterprise

Composable yaklasim yalnizca e-ticaretle sinirli degildir. Composable enterprise, tum kurumsal yazilim ekosistemine bu prensibi uygular. ERP, CRM, HR ve diger is uygulamalari PBC'ler olarak tanimlanir ve API'ler araciligiyla entegre edilir.

Smart Maple olarak Ankara merkezli projelerimizde composable enterprise yaklasimini ozellikle orta ve buyuk olcekli isletmelerin dijital donusum sureclerinde uyguluyoruz. Mevcut sistemlerin tamamen degistirilmesi yerine, kademeli olarak PBC'lere donusturulmesi daha surdurulebilir sonuclar veriyor.

API Orkestrasyon Katmani

Composable architecture'de bilesenleri bir arada tutan ve is akislarini yoneten orkestrasyon katmani kritik bir rol ustlenir. Bu katman, istemci uygulamalarin birden fazla PBC ile dogrudan iletisim kurmasi yerine, tek bir noktadan koordineli erisim saglar.

Orkestrasyon Katmaninin Sorumlulklari

• API Gateway: Dis dunyanin sistemle iletisim kurdugu tek giris noktasi. Kimlik dogrulama, hiz sinirlandirma ve istek yonlendirme islevlerini ustlenir.
• BFF (Backend for Frontend): Her kanal icin ozellestirilmis API katmani. Mobil uygulama ile web uygulamasinin farkli veri ihtiyaclarini karsilar.
• Is Akisi Motoru: Birden fazla PBC'yi iceren karmasik is sureclerini yonetir. Ornegin bir siparis sureci; stok kontrolu, odeme isleme, fatura olusturma ve kargo baslama adimlarini icerir.
• Olay Yolu (Event Bus): PBC'ler arasinda asenkron iletisim saglar. Bir PBC'deki degisiklik, ilgili diger PBC'leri olay mekanizmasiyla bilgilendirir.

Ornek Orkestrasyon Akisi

Bir e-ticaret siparis surecinde orkestrasyon katmani su sekilde calisir:

1. Kullanici siparis verir, istek API Gateway'e ulasir
2. Orkestrasyon katmani Stok PBC'sine urun musaitligini sorar
3. Stok uygunsa Odeme PBC'sine odeme istegi gonderilir
4. Odeme basariliysa Siparis PBC'sinde kayit olusturulur
5. Siparis olayi yayinlanir; Bildirim PBC'si mussteriye e-posta gonderir
6. Lojistik PBC'si kargolama surecini baslatir

Bu akista her adim bagimsiz bir PBC tarafindan yurutulur ve orkestrasyon katmani butun sureci koordine eder.

Best-of-Breed ve Suite Yaklasimi

Composable architecture, best-of-breed (her alanda en iyi cozumu secme) yaklasimini benimser. Ancak bu yaklasiminj avantajlari kadar zorlulklari da vardir.

Best-of-Breed Avantajlari

• Her alanda en iyi teknolojiyi kullanma imkani
• Vendor lock-in riskinin azalmasi
• Bagimsiz guncelleme ve degistirme esnekligi
• Inovasyona aciklik; yeni bir teknoloji ciktiginda yalnizca ilgili bilesen degistirilir

Best-of-Breed Zorluklari

• Entegrasyon karmasikligi artar
• Birden fazla saticayla iliski yonetimi gerekir
• Veri tutarliligi saglamak zorlusir
• Toplam sahip olma maliyeti baslangicta yuksek olabilir

Suite Yaklasimi

Suite yaklasiminda tek bir saticidan tum bilesenleri almak mumkundur. Salesforce, SAP veya Oracle gibi buyuk saticillar genis urun portfoyleri sunar. Suite yaklasimi daha az entegrasyon gerektirirken, esneklik ve inovasyon hizindan odun verir.

Hibrit Yaklasim

Pratikte cogu organizasyon hibrit bir yaklasim benimser. Kritik is yetenekleri icin best-of-breed cozumler secilirken, daha az stratejik alanlar icin suite bilesenleri kullanilir. Bu denge, organizasyonun teknik olgunluguna ve kaynaklarina gore belirlenir.

Monolitten Composable Mimariye Gecis Stratejileri

Mevcut bir monolitik sistemi composable mimariye donusturmek, dikkatli planlama ve kademeli uygulama gerektiren bir surecttir. Asagida kanisitlanmis gecis stratejilerini inceliyoruz.

Strangler Fig Pattern

En yaygin ve guvenli gecis stratejisidir. Monolitik sistemin etrafina yeni composable bilesenler yerlestirilir. Trafik kademeli olarak yeni bilesenlere yonlendirilir. Monolitik sistem zamanla kuculur ve sonunda tamamen devre disi kalir.

Uygulama adimlari:

1. Monolitin onune bir API Gateway yerlestirilir
2. Yeni bir is yetenegi PBC olarak gelistirilir
3. API Gateway, ilgili istekleri yeni PBC'ye yonlendirir
4. Eski islevsellik monolitten cikarilir
5. Surev diger is yetenekleri icin tekrarlanir

Domain-Driven Decomposition

Is alanina dayali ayrsstirma stratejisinde, once is alanlari (domain) net olarak tanimlenir. Her is alani potansiyel bir PBC adayidir. Ayrrstirma sirasinda is alanlarinin sinirlarini belirlemek icin Event Storming gibi teknikler kullanilir.

Kademeli Gecis Plani

Asama	Sure	Hedef
Kesfetme	1-2 ay	Mevcut sistemin analizi, PBC adaylarinin belirlenmesi
Altyapi	2-3 ay	API Gateway, orkestrasyon katmani, CI/CD pipeline
Pilot PBC	2-4 ay	Dusuk riskli bir is yeteneginin PBC olarak cikarilmasi
Genisleme	6-12 ay	Diger is yeteneklerinin kademeli olarak PBC'ye donusumu
Optimizasyon	Surekli	Performans, guvenlik ve operasyonel iyilestirmeler

Smart Maple olarak Ankara merkezli projelerimizde monolitten composable mimariye gecis sureclerinde Strangler Fig Pattern'i tercih ediyoruz. Bu yaklasim, mevcut sistemin calismasini kesintiye ugratmadan kademeli bir donusum sagliyor.

Composable Architecture Desenleri

Pratikte composable architecture farkli desenlerle uygulanabilir. Projenin gereksinimlerine gore bu desenlerden biri veya birden fazlasi birlikte kullanilir.

Mesh App and Service Architecture (MASA)

MASA deseni, uygulamalarin ve hizmetlerin bir ag (mesh) icinde birbirine baglandigi bir yaklasimdir. Her dugum hem hizmet saglayici hem de hizmet tuketici olabilir. Service mesh teknolojileri (Istio, Linkerd) bu desenin altyapisini olusturur.

Cell-Based Architecture

Hucre tabanli mimari, her is yetenegini izole bir "hucre" olarak tasarlar. Her hucre kendi veri deposu, is mantigi ve API katmanini icerir. Hucreler arasinda yalnizca tanimli mesajlasma protokolleri uzerinden iletisim kurulur. Bu desen, yuksek izolasyon gerektiren sistemlerde tercih edilir.

Event-Driven Composable Architecture

Olaya dayali composable mimaride bilesenler arasindaki iletisim buyuk olcude asenkron olaylar uzerinden gerceklesir. Apache Kafka veya RabbitMQ gibi olay akis platformlari kullanilir. Bu desen, gercek zamanli veri isleme ve yuksek hacimli islem gerektiren senaryolarda etkilidir.

Micro Frontend Composition

Composable yaklasim yalnizca backend ile sinirli degildir. Micro frontend deseni, kullanici arayuzunun de bagimsiz bilesenlerden olusturulmasini saglar. Her PBC kendi frontend bilesenini sunar ve bu bilesenler bir kabuk uygulama (shell application) icerisinde birlstirilir.

Basari Icin Dikkat Edilmesi Gerekenler

Composable architecture'e gecis, yalnizca teknik bir donusum degil, ayni zamanda organizasyonel bir degisimdir. Basarili bir uygulama icin su noktalara dikkat edilmelidir:

Teknik gereksinimler:

• Guclu API tasarimi ve dokumantasyonu (OpenAPI/Swagger)
• Kapsamli izleme ve gozlemlenebilirlik altyapisi
• Otomatik test ve surekli entegrasyon surecleri
• Dagitik sistemlerde veri tutarliligi mekanizmalari (saga pattern, eventual consistency)

Organizasyonel gereksinimler:

• Is ve teknoloji ekipleri arasinda yakin is birligi
• PBC'lere hizalanmis ekip yapilari
• API kontrati yonetimi icin yonetisim surecleri
• Teknik ve is perspektifinden karar alma mekanizmalari

Kacilnilmasi gereken hatalar:

• Tum sistemi ayni anda donusturmeye calismak
• Is alani sinirlarini yanlis belirlemek
• Orkestrasyon katmanini asiri karmasik tasarlamak
• Teknik borcu goz ardi etmek
• Yeterli izleme ve loglama olmadan dagitik sisteme gecmek

Sonuc

Composable architecture, dijital cagin hizla degisen gereksinimlerine yanit verebilen esnek ve olceklenebilir sistemler insaa etmenin modern yoludur. MACH prensipleri, PBC yaklasimi ve API orkestrasyon katmani bu mimarinin temel taslarini olusturur.

Ancak her organizasyon icin dogru yaklasim farklidir. Kucuk bir startup icin monolitik bir baslangic hala mantiklidir. Buyuyen ve dijital donusum geciren organizasyonlar ise composable yaklasimdan en fazla faydayi gorecektir. Onemli olan, kademeli bir gecis stratejisi izlemek, is alani sinirlarini dogru belirlemek ve organizasyonel hazirligi ihmal etmemektir.

Composable mimari, dogru uygulandiginda organizasyonlara rakiplerinden daha hizli hareket etme, yeni kanallara hizla acilma ve teknoloji yatirimlarindan maksimum deger elde etme imkani sunar.