Mikroframeworklerin, açık modüller, middleware ve net sınırlar kullanarak takımların özel mimariler kurmasına nasıl izin verdiğini, artı ödünleri, desenleri ve dikkat edilecek noktaları öğrenin.
Mikroframeworkler, temel işlevlere odaklanan hafif web çerçeveleridir: bir isteği almak, doğru handler’a yönlendirmek ve yanıt döndürmek. Tam yığın framework’lerin aksine, genellikle ihtiyacınız olabilecek her şeyi (admin panelleri, ORM/veritabanı katmanları, form oluşturucular, arka plan işleri, kimlik doğrulama akışları) paketlemezler. Bunun yerine küçük, stabil bir çekirdek sağlarlar ve ürününüzün gerçekten gerektirdiği şeyleri eklemenize izin verirler.
Tam yığın bir framework, tamamen döşenmiş bir ev satın almaya benzer: tutarlı ve kullanışlıdır ama yeniden şekillendirmesi zordur. Bir mikroframework ise yapısal olarak sağlam ama boş bir alan gibidir: odaları, mobilyaları ve altyapıyı siz belirlersiniz.
Bu özgürlük, özel mimari dediğimiz şeyin özüdür—takımınızın ihtiyaçları, domain’iniz ve operasyonel kısıtlarınız etrafında şekillenen bir sistem tasarımı. Basitçe: bileşenleri (loglama, veritabanı erişimi, doğrulama, auth, arka plan işleme) siz seçersiniz ve nasıl bağlanacaklarına siz karar verirsiniz; önceden tanımlanmış “tek doğru yol”u kabul etmezsiniz.
Takımlar genellikle mikroframeworklere şu isteklerle yönelir:
Mikroframeworklerin modüler tasarımı nasıl desteklediğine odaklanacağız: yapı taşlarını birleştirmek, middleware kullanımı ve bağımlılık enjeksiyonu eklemek—projenizi bir bilim deneyi haline getirmeden.
Belirli framework’leri satır satır karşılaştırmayacağız veya mikroframeworklerin her zaman daha iyi olduğunu iddia etmeyeceğiz. Amaç, yapılandırmayı kasıtlı seçmenize yardımcı olmak ve gereksinimler değiştikçe güvenli biçimde evrilmesini sağlamak.
Mikroframeworkler, uygulamanızı önceden inşa edilmiş bir ev değil, bir kit gibi ele aldığınızda daha iyi çalışır. Dayatmacı bir yığını kabul etmek yerine, küçük bir çekirdek ile başlayıp yetenekleri ancak karşılığını verdiğinde eklersiniz.
Pratik bir “çekirdek” genellikle şunlardır:
Bu, çalışan bir API endpoint’i veya web sayfası göndermek için yeterlidir. Diğer her şey somut bir gerekçe olana kadar isteğe bağlıdır.
Kimlik doğrulama, doğrulama veya loglama gerektiğinde, bunları ayrı bileşenler olarak ekleyin—tercihen net arayüzlerin arkasında. Bu, mimarinizi anlaşılır tutar: her yeni parçanın “hangi problemi çözüyor?” ve “nereye takılıyor?” sorularına cevap vermesi gerekir.
“Sadece ihtiyacın olanı ekle” modül örnekleri:
Başlangıçta sizi sıkıştırmayacak çözümleri seçin. Derin framework sihrinden ziyade ince sarmalayıcılar ve konfigürasyon tercih edin. Bir modülü iş mantığını yeniden yazmadan değiştirebiliyorsanız doğru yapıyorsunuz demektir.
Mimari seçimler için basit bir tamamlanma tanımı: takım her modülün amacını açıklayabiliyor, bir iki günde değiştirebiliyor ve bağımsız test edebiliyor olmalı.
Mikroframeworkler tasarım gereği küçük kalır; bu da uygulamanızın “organlarını” seçmenize izin verir. Bu, özel mimariyi pratik kılan şeydir: minimal başlayıp gerçek bir ihtiyaç ortaya çıktıkça parçalar eklersiniz.
Çoğu mikroframework tabanlı uygulama, URL’leri controller’lara (veya daha basit request handler’lara) eşleyen bir router ile başlar. Controller’lar özelliklere (faturalandırma, hesaplar) ya da arayüze (web vs. API) göre düzenlenebilir; bu, kodu nasıl korumak istediğinize bağlıdır.
Middleware tipik olarak istek/yanıt akışını sarar ve çapraz-kesit endişeleri için en iyi yerdir:
Middleware bileşebilir olduğu için bunu global (her şey loglanmalı) veya belirli rotalara (admin endpoint’leri daha sıkı auth gerektirir) uygulayabilirsiniz.
Mikroframeworkler nadiren bir veri katmanı dayatır, bu yüzden takımınıza ve iş yükünüze uygun bir şey seçebilirsiniz:
İyi bir desen, veri erişimini bir repository veya servis katmanının arkasına koymaktır; böylece araç değiştirme handler’lara yayılmaz.
Her ürün ilk günden itibaren asenkron işlem gerektirmez. Gerektiğinde, bir job runner ve kuyruk ekleyin (e‑posta gönderimi, video işleme, webhook’lar). Arka plan işleri, iş mantığınıza HTTP katmanından ayrı bir “giriş noktası” gibi davranmalı; kuralları çoğaltmak yerine aynı servisleri paylaşmalıdır.
Middleware, mikroframeworklerin en büyük verimliliği sağladığı yerdir: tüm isteklerin alması gereken işleri her route handler’ı şişirmeden yapmanızı sağlar. Amaç basit: handler’ları iş mantığına odaklı tutmak, tesisatla ilgili işleri middleware’e bırakmak.
Her endpoint’te aynı kontrolleri ve başlıkları tekrarlamak yerine, bir kez middleware ekleyin. Temiz bir handler şu şekilde görünmelidir: girdiyi ayrıştır, bir servisi çağır, yanıtı döndür. Diğer her şey—auth, loglama, doğrulama varsayılanları, yanıt biçimlendirme—önce veya sonra gerçekleşebilir.
Sıra davranıştır. Yaygın ve okunabilir bir dizi:
Sıkıştırma çok erken çalışırsa hataları kaçırabilir; hata yönetimi çok geç çalışırsa stack trace sızdırabilir veya tutarsız formatlar dönebilirsiniz.
X-Request-Id başlığı ekleyin ve bunu loglara dahil edin.{ error, message, requestId }).Middleware’i amaçlarına göre gruplayın (gözlemlenebilirlik, güvenlik, ayrıştırma, yanıt şekillendirme) ve doğru kapsamda uygulayın: gerçekten evrensel kurallar için global, belirli alanlar için route-group middleware. Her middleware’e net bir isim verin ve kurulumun yakınında beklenen sırayı kısa bir yorumla belgeleyin ki gelecekteki değişiklikler sessizce davranışı bozmasın.
Mikroframework size ince bir “istek girer, yanıt çıkar” çekirdeği sağlar. Geri kalan her şey—veritabanı erişimi, önbellek, e‑posta, üçüncü taraf API’ler—değiştirilebilir olmalı. İşte burada Inversion of Control (IoC) ve Dependency Injection (DI) devreye girer, kod tabanınızı bir bilim deneyi haline getirmeden.
Bir özellik veritabanına ihtiyaç duyduğunda, onu doğrudan orada oluşturmak cazip gelebilir ("burada yeni veritabanı istemcisi"). Dezavantaj: her “alışverişe giden” yer o özel veritabanı istemcisine sıkı sıkıya bağlı olur.
IoC bunu tersine çevirir: özellik neye ihtiyaç duyduğunu söyler, uygulama kablajı onu verir. Özelliğiniz yeniden kullanılabilir ve değiştirmesi kolay olur.
Dependency Injection, bağımlılıkları içeride yaratmak yerine dışarıdan geçirmek demektir. Bir mikroframework kurulumunda bu genellikle başlatmada yapılır:
Büyük bir DI container’a ihtiyaç yoktur. Basit bir kural: bağımlılıkları bir yerde oluşturun ve aşağı doğru geçirin.
Bileşenleri değiştirilebilir kılmak için, "neye ihtiyacınız olduğunu" küçük bir arayüz olarak tanımlayın, sonra belirli araçlar için adaptörler yazın.
Örnek desen:
UserRepository (arayüz): findById, create, listPostgresUserRepository (adaptör): Postgres kullanarak bu metodları uygularInMemoryUserRepository (adaptör): testler için aynı metodları uygularİş mantığınız sadece UserRepository’yi bilir, Postgres’i bilmez. Depolamayı değiştirmek konfigürasyon seçimi olur, yeniden yazma değil.
Aynı fikir harici API’ler için de geçerlidir:
PaymentsGateway arayüzüStripePaymentsGateway adaptörüFakePaymentsGatewayMikroframeworkler konfigürasyonun modüller arasında rastgele dağılmasını kolaylaştırır—buna direnin.
Sürdürülebilir bir desen:
Bunu yapınca ana hedefi elde edersiniz: bileşenleri yeniden yazmadan takas etmek. Veritabanını değiştirmek, bir API istemcisini yenilemek veya bir kuyruk eklemek kablolama katmanında küçük bir değişiklik olur—geriye kalan kod stabil kalır.
Mikroframeworkler kodunuzu tek bir “doğru yol”a zorlamaz. Bunun yerine routing, istek/yanıt işleme ve birkaç uzatma noktası sağlar—böylece takım büyüklüğünüze, ürün olgunluğunuza ve değişim hızına uyan desenleri benimseyebilirsiniz.
Bu, tanıdık “temiz ve basit” kuruludur: controller’lar HTTP kaygılarını ele alır, servisler iş kurallarını tutar ve repository’ler veritabanıyla konuşur.
Domaininiz açıksa, takımınız küçük‑orta büyüklükteyse ve kod koymak için öngörülebilir yerler istiyorsanız iyi uyar. Mikroframeworkler bunu doğal olarak destekler: rotalar controller’lara eşlenir, controller’lar servisleri çağırır ve repository’ler hafif manuel kompozisyonla kablolanır.
Altıgen mimari, sisteminizin bugün seçtiğiniz bileşenlerden (veritabanı, mesaj kuyruğu, üçüncü taraf API’ler, hatta UI) daha uzun ömürlü olmasını bekliyorsanız faydalıdır.
Mikroframeworkler burada güzel çalışır çünkü “adaptör” katmanı genellikle HTTP handler’larınız ve domain komutlarına ince bir çeviri adımıdır. Portlar domain’deki arayüzlerdir, adaptörler onları uygular (SQL, REST istemcileri, kuyruklar). Framework kenarda, merkezde değil.
Operasyonel yükü artırmadan mikroservis benzeri netlik istiyorsanız, modüler bir monolit güçlü bir seçenek olabilir. Tek deploy edilebilir uygulamayı korursunuz, ama onu özellik modüllerine (ör. Billing, Accounts, Notifications) açık public API’lerle bölersiniz.
Mikroframeworkler bunu kolaylaştırır çünkü her modül kendi rotalarını, bağımlılıklarını ve veri erişimini kaydedebilir; böylece sınırlar görünür olur ve kazara aşılması zorlaşır.
Bu üç desenin her birinde fayda aynıdır: kuralları siz seçersiniz—klasör düzeni, bağımlılık yönü ve modül sınırları—mikroframework ise takılacak küçük, stabil bir yüzey sağlar.
Mikroframeworkler küçük başlamayı ve esnek kalmayı kolaylaştırır, ama daha büyük soruyu cevaplamazlar: sisteminiz hangi “şekli” olmalı? Doğru seçim teknolojiye değil, takım büyüklüğüne, sürüm sıklığına ve koordinasyonun ne kadar acı verdiğine bağlıdır.
Bir monolit tek deploy edilebilir birim olarak gönderilir. Genellikle en hızlı yoludur: tek build, tek log kümesi, hata ayıklamak için tek yer.
Bir modüler monolit hâlâ tek deploy edilebilirdir, ama iç olarak net modüllere ayrılmıştır (paketler, bounded context’ler, özellik klasörleri). Kod tabanı büyüdüğünde sıklıkla en iyi "sonraki adım" budur—özellikle mikroframeworklerle, modülleri açık tutabilirsiniz.
Mikroservisler deployable birimleri birden çok servise böler. Bu ekipler arasındaki coupling’i azaltabilir ama operasyonel işi çarpar.
Bir sınırı şu durumlarda ayırın:
Sadece klasör büyük diye bölmekten kaçının veya servislerin aynı veritabanı tablolarını paylaşacağı durumlarda bölmeyin. Bu, henüz kararlı bir sınır bulamadığınızın işaretidir.
Bir API gateway istemcileri basitleştirebilir (tek giriş noktası, merkezi auth/hız sınırlama). Dezavantaj: çok akıllı hale geldikçe darboğaz ve tek hata noktası olabilir.
Paylaşılan kütüphaneler geliştirmeyi hızlandırır (ortak doğrulama, loglama, SDK’lar) ama gizli coupling de yaratır. Birden fazla servisin aynı anda yükseltme zorunluluğu varsa, dağıtık bir monolit yaratırsınız.
Mikroservisler tekrar eden maliyetler getirir: daha fazla deploy pipeline’ı, versiyonlama, servis keşfi, izleme, izleme (tracing), olay müdahalesi ve on-call rotasyonları. Takımınız bu makinayı rahatça çalıştıramıyorsa, mikroframework bileşenleriyle inşa edilmiş modüler bir monolit genellikle daha güvenli mimaridir.
Mikroframework size özgürlük verir, ama sürdürülebilirlik tasarlamanız gereken bir şeydir. Amaç, “özel” parçaların kolay bulunur, kolay değiştirilir ve kötüye kullanılmasının zor olduğu bir yapı kurmaktır.
Bir dakikada açıklayabileceğiniz ve kod inceleme ile uygulayabileceğiniz bir yapı seçin. Pratik bir ayrım:
app/ (kompozisyon kökü: modülleri kablolayan yer)modules/ (iş yetenekleri)transport/ (HTTP yönlendirme, istek/yanıt eşlemesi)shared/ (çapraz‑kesit yardımcıları: konfig, loglama, hata tipleri)tests/İsimlendirmeyi tutarlı tutun: modül klasörleri isimleri isim (billing, users) ile ve giriş noktaları öngörülebilir (index, routes, service).
Her modülü küçük bir ürün gibi ele alın:
modules/users/public.ts)modules/users/internal/*)modules/orders/internal/db.ts gibi “reach-through” importlara izin vermeyin. Başka bir bölüm buna ihtiyaç duyuyorsa, onu public API’ye taşıyın.
Küçük servisler bile temel görünürlüğe ihtiyaç duyar:
Bunları shared/observability içinde tutun ki her route handler aynı kuralları kullansın.
Hataları istemciler için öngörülebilir, insanlar için anlaşılır yapın. Tek bir hata şekli tanımlayın (örn. code, message, details, requestId) ve endpoint başına bir doğrulama şeması belirleyin. Dahili istisnalar→HTTP yanıtı eşlemesini merkezileştirin ki handler’lar iş mantığına odaklansın.
Hedefiniz hızlı ilerlemek ama mikroframework tarzı mimariyi açık tutmaksa, Koder.ai iskelet oluşturma ve yineleme aracı olarak faydalı olabilir—iyi tasarımın yerine değil, destekçisi olarak. Sohbette modül sınırlarınızı, middleware yığınınızı ve hata formatınızı tarif ederek çalışan bir başlangıç uygulaması (ör. React frontend ile Go + PostgreSQL backend) oluşturup sonra kablolamayı kasıtlı biçimde düzeltebilirsiniz.
İki özellik özellikle özel mimari çalışmalarına iyi uyar:
Koder.ai source code export desteklediği için, üretilen içeriğin sahipliği sizde kalır ve repoda el yapımı bir mikroframework projesi gibi evriltilebilir.
Mikroframework tabanlı sistemler “el yapımı” hissi verebilir; bu yüzden testler tek bir framework’ün kuralları değil, parçalar arasındaki dikişleri korumaya odaklanmalıdır. Amaç, değişiklikleri kapsamlı entegrasyon çalıştırmak zorunda kalmadan güven duymaktır.
İş kuralları için (doğrulama, fiyatlama, izin mantığı) hızlı birim testlerine başlayın—bunlar hızlıdır ve hatayı net gösterir. Sonra, kablolamayı test eden az sayıda yüksek katma değer entegrasyon testi ekleyin: routing → middleware → handler → persistence sınırı. Bu, bileşenler birleştiğinde ortaya çıkan ince hataları yakalar.
Middleware genelde çapraz‑kesit davranışları saklar (auth, loglama, hız limiti). Bunu bir pipeline gibi test edin:
Handler’lar için, iç fonksiyon çağrıları yerine halka açık HTTP şekli (status kodları, başlıklar, yanıt gövdesi) test edilmeli. Bu, içler değişse bile testlerin stabil kalmasını sağlar.
Gerçek bağımlılıkları fake’lerle değiştirmek için DI kullanın veya yapıcı parametreler kullanın:
Birden fazla ekip veya servis bir API’ye güveniyorsa, istek/yanıt beklentilerini sabitleyen kontrat testleri ekleyin. Sağlayıcı tarafında kontrat testleri, tüketicileri kazara bozmamanızı garanti eder, framework ve iç modüller evrilse bile.
Mikroframeworkler özgürlük verir, ama özgürlük otomatik olarak açıklık sağlamaz. Ana riskler genellikle ekip büyüdüğünde, kod tabanı genişlediğinde ve “geçici” kararlar kalıcı hale geldiğinde ortaya çıkar.
Daha az yerleşik kural olduğunda, iki ekip aynı özelliği iki farklı tarzda yazabilir (routing, hata yönetimi, yanıt formatı, loglama). Bu tutarsızlık incelemeleri yavaşlatır ve işe alım sürecini zorlaştırır.
Basit bir koruyucu: kısa bir “servis şablonu” dokümanı yazın (proje yapısı, isimlendirme, hata formatı, log alanları) ve bunu bir başlangıç deposu ile birkaç lint kuralı aracılığıyla zorlayın.
Projeler temiz başlar sonra utils/ klasörü sessizce ikinci bir framework’e dönüşebilir. Modüller yardımcılar, sabitler ve global durum paylaştıkça sınırlar bulanıklaşır ve değişiklikler sürpriz kırılmalara yol açar.
Açık paylaşılan paketleri tercih edin ve sürümlendirin; paylaşımı sınırlı tutun: tipler, arayüzler ve iyi test edilmiş primitivler. Bir yardımcı iş kurallarına bağımlıysa, büyük olasılıkla domain modülünde olmalıdır, utils/ içinde değil.
Auth, yetkilendirme, girdi doğrulama ve hız sınırlamayı elle bağlarken bir rotayı atlamanız, bir middleware’i unutmamanız veya sadece “mutlu yol” girdilerini doğrulamanız kolaydır.
Güvenlik varsayılanlarını merkezileştirin: güvenli başlıklar, tutarlı auth kontrolleri ve uçta doğrulama. Korunan endpoint’lerin gerçekten korunup korunmadığını doğrulayan testler ekleyin.
Planlanmamış middleware katmanları ek yük getirir—özellikle birden fazla middleware gövdeleri parse ediyor, depolamaya erişiyor veya log serileştiriyorsa.
Middleware’i küçük ve ölçülebilir tutun. Standart sırayı belgeleyin ve yeni middleware’i maliyet açısından gözden geçirin. Şişkinlikten şüphelenirseniz istekleri profil çıkarın ve gereksiz adımları kaldırın.
Mikroframeworkler size seçenekler sunar—ancak seçeneklerin bir karar süreci olmalı. Amaç, ekibinizin sorunsuzca kurup işletip değiştirebileceği bir şekil seçmektir, “en iyi” mimariyi bulmak değil.
Monolit veya mikroservis seçmeden önce şunlara cevap verin:
Emin değilseniz, mikroframework ile inşa edilmiş modüler bir monolit ile başlayın. Bu, sınırları açık tutarken göndermeyi kolay kılar.
Mikroframeworkler sizin için tutarlılığı zorlamaz, bu yüzden baştan kuralları seçin:
Bir sayfalık "service contract" dokümanı /docs içinde çoğunlukla yeterlidir.
Her yerde ihtiyaç duyacağınız çapraz‑kesit parçalarla başlayın:
Bunları paylaşılan modüller olarak ele alın, kopyala‑yapıştır snippet’ler olarak değil.
Mimari gereksinimlere göre değişmelidir. Her çeyrekte, deploy’ların nerede yavaşladığını, hangi parçaların farklı ölçeklendiğini ve en çok neyin kırıldığını gözden geçirin. Bir alan darboğaz haline geldiyse, bir sonraki ayırma adayı odur—tüm sistemi bölmek değil.
Bir mikroframework kurulumu nadiren baştan tam tasarlanmış olur. Çoğunlukla tek bir API, tek bir takım ve sıkı bir teslim tarihi ile başlar. Değer, ürün büyüdükçe ortaya çıkar: yeni özellikler gelir, daha fazla kişi koda dokunur ve mimari esnemeli ama kopmamalıdır.
Minimal servise başlarsınız: routing, istek ayrıştırma ve bir veritabanı adaptörü. Çoğu mantık endpoint’lere yakın durur çünkü gönderme hızı önemlidir.
Auth, ödemeler, bildirimler ve raporlama ekledikçe bunları modüllere ayırırsınız (klasörler veya paketler) ve net public arayüzler sunarsınız. Her modül kendi modellerinin, iş kurallarının ve veri erişiminin sahibi olur, sadece gerekeni dışarı açar.
Loglama, auth kontrolleri, hız sınırlama ve istek doğrulama middleware’e taşınır ki her endpoint tutarlı davransın. Sıra önemli olduğundan bunu belgelemelisiniz.
Belgeleyin:
Modüller çok fazla iç paylaşmaya başladığında, build süreleri belirgin şekilde yavaşladığında veya "küçük bir değişiklik" için birden fazla modülde düzenleme yapmak gerektiğinde refaktörleyin.
Takımları paylaşılan deploy’lar yüzünden bloklanıyorsa, farklı parçaların farklı ölçek gereksinimleri varsa veya bir entegrasyon sınırı zaten ayrı bir ürün gibi davranıyorsa, servisleri ayırmayı düşünün.
Mikroframeworkler, uygulamayı dayatılmış bir yığın etrafında şekillendirmek yerine domain’iniz etrafında şekillendirmek istediğinizde iyi çalışır. Açıklıkı konforun önüne koyan takımlar için özellikle uygundur: birkaç ana yapı taşını seçip korumayı kabul edersiniz, karşılığında kod tabanı gereksinimler değiştikçe anlaşılır kalır.
Esnekliğiniz ancak onu birkaç alışkanlıkla korursanız işe yarar:
İki hafif belgeyle başlayın:
Son olarak, kararlarınızı aldıkça bunları belgeleyin—kısa notlar bile yardımcı olur. Repoda bir “Architecture Decisions” sayfası tutun ve periyodik olarak gözden geçirin ki dünkü kestirme yollar bugünün kısıtlarına dönüşmesin.
Bir mikroframework, temel ihtiyaçlara odaklanır: yönlendirme, istek/yanıt işleme ve temel genişletme noktaları.
Tam paket bir framework genellikle birçok “hazır” özelliği (ORM, kimlik doğrulama, admin, formlar, arka plan işleri) içinde barındırır. Mikroframeworkler, kolaylık karşılığında daha fazla kontrol verir—sadece ihtiyacınız olanı eklersiniz ve bileşenlerin nasıl bağlanacağına siz karar verirsiniz.
Mikroframeworkler şu durumlar için uygundur:
“Kullanışlı en küçük çekirdek” genellikle şunlardır:
Oradan başlayın: bir endpoint gönderin, sonra gerçekten gerektikçe modüller ekleyin (auth, doğrulama, gözlemlenebilirlik, kuyruklar).
Ara katman (middleware) genelde geniş kapsamlı olan endişeler için en uygunudur:
Rota handler’larını iş mantığına odaklı tutun: parse → servisi çağır → yanıt döndür.
Sıra davranışı değiştirir. Yaygın, güvenilir bir sıra:
Kurulum kodunun yakınına sırayı belgelendirin ki gelecekteki değişiklikler cevap formatlarını veya güvenlik varsayımlarını gizlice bozmasın.
Inversion of Control, iş kodunuzun kendi bağımlılıklarını oluşturmasını engellemek demektir (kodunuz “alışverişe” gitmez). Bunun yerine uygulama sarmalaması gerekli olanları sağlar.
Pratikte: veritabanı istemcisini, logger’ı ve API istemcilerini başlangıçta oluşturun, sonra bunları servislere/handler’lara verin. Bu, sıkı bağlılığı azaltır ve test etmeyi kolaylaştırır.
Gerekmez. Mikroframework ile çoğu DI faydasını basit bir kompozisyon kökünden elde edebilirsiniz:
Bağımlılık grafiği elle yönetilemeyecek kadar karmaşık olursa bir container ekleyin—varsayılan olarak karmaşıklıkla başlamayın.
Depolama ve harici API’leri küçük arayüzlerin (portların) arkasına koyun, sonra adaptörler yazın:
UserRepository arayüzü: findById, create, listPostgresUserRepository üretim içinSınırları görünür tutan pratik bir yapı:
app/ kompozisyon kökü (modülleri birleştirir)modules/ iş modülleri (doman yetenekleri)transport/ HTTP yönlendirme + istek/yanıt eşlemesiİş kuralları için hızlı birim testlerine öncelik verin, sonra tüm boru hattını (routing → middleware → handler → persistence sınırı) çalıştıran yüksek değerli entegrasyon testlerinden bazılarına yatırım yapın.
DI/fake’ler kullanarak harici servisleri izole edin (sahte e‑posta/ödeme istemcileri, bellek içi repository’ler). Birden fazla ekip API’lere bağımlıysa, bozmamayı garantilemek için kontrat testleri ekleyin.
InMemoryUserRepository testler içinHandler’lar/servisler arayüze bağımlı olsun, somut araca değil. Veritabanını veya üçüncü taraf sağlayıcıyı değiştirmek konfigürasyon/wiring değişikliği olur, yeniden yazma değil.
shared/tests/Modül genel API’lerini zorunlu kılın (örn. modules/users/public.ts) ve iç yapılara doğrudan erişimden kaçının.