Skip to main content

> temiz_mimari_ve_bağımlılıkların_tersine_çevrilmesi_kuralı

Temiz Mimari ve Bağımlılıkların Tersine Çevrilmesi Kuralı

Yüksek verimli canlı mimarilerde Temiz Mimari ve Bağımlılıkların Tersine Çevrilmesi Kuralı yapısını nasıl doğru kurar ve yönetirsiniz?

Stack: SOFTWARE ARCHITECTURE STACK →Senior (L5)antipattern

ÖZET VE TEKNİK CEVAP

Temiz Mimari Bağımlılık Kuralı, tüm kaynak kod bağımlılıklarının yalnızca içeriye (yüksek seviyeli iş kurallarına) bakmasını şart koşar; veritabanı veya web protokollerinin çekirdek iş mantığına sızması test edilebilirliği yok eder ve sistemi kilitler.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Temiz Mimari'de (ve Altıgen/Soğan mimarilerinde) yazılım iç içe halkalara ayrılır: En içte Alan Varlıkları (Domain), ortada Kullanım Senaryoları (Use Cases), en dışta ise Çatılar ve Altyapı (PostgreSQL, Express, Stripe SDK) yer alır. Temel kural: İç katmanlar dış katmanlardan tamamen habersiz olmalıdır. Geliştiriciler alan servislerine ORM veya HTTP sınıfları import ettiğinde mimari çöker.

2. Doğru Kullanım Senaryosu

Bağımlılık Kuralı, dış halkaların (altyapı, web, veritabanı) iç halkalara (kullanım senaryoları, alan) bağımlı olmasını, ancak iç halkaların ASLA dış halkalara bağımlı OLMAMASINI şart koşan temel kısıtlamadır.

3. Prodüksiyon Arıza Modları

Ham HTTP `Request` / `Response` nesnelerini veya veritabanı satırlarını doğrudan Alan kullanım senaryolarına parametre geçmek. Alan iş mantığı varlıklarının üzerine doğrudan veritabanı ORM dekoratörleri (`@Entity`, `@Column`) eklemek. Alan sınıfları içinde constructor enjeksiyonu yerine `new PostgresClient()` ile doğrudan veritabanı istemcisi oluşturmak.

4. Teşhis ve Telemetri Sinyalleri

alan varlığının veritabanı ORM anotasyonlarıyla kirletilmesi, iş mantığının port arayüzü yerine doğrudan HTTP kütüphanesini çağırması, framework güncellemesinin tüm iş mantığını yeniden yazmaya zorlaması

5. Önleme ve Mimari Bariyerler

Mimari linter araçları (Java için ArchUnit, TypeScript için `eslint-plugin-boundaries`) ile katman bağımlılık kurallarını zorunlu kılın. Docker veya mock kütüphanelerine ihtiyaç duymadan <1 milisaniyede çalışan saf bellek içi alan birim testleri yazın. Altyapı adaptörü sınırında veritabanı modellerini açıkça Alan Varlıklarına (Domain Entities) dönüştürün.

6. Mimari Ödünleşimler (Trade-offs)

İş kurallarını doğrudan çatılara (Prisma, Spring, TypeORM) bağlamak, birim testler için veritabanı ayağa kaldırmayı zorunlu kılar, framework güncellemelerini riskli yeniden yazımlara dönüştürür ve altyapı değişimini engeller.

Vaka İncelemesi (TinyCTO Örneği)

Bağımlılık Kuralını tavizsiz korumak için Bağımlılıkların Tersine Çevrilmesi (DIP) uygulanır: 1. **Portlar (İç Katmandaki Arayüzler):** Kullanım senaryosu veri erişimi için bir arayüz tanımlar (`UserRepository { findById(id): User }`). Bu arayüz sıfır altyapı bağımlılığı ile çekirdekte yaşar. 2. **Adaptörler (Dış Katmandaki Uygulamalar):** Altyapı katmanı portu uygular (`PostgresUserRepository implements UserRepository`). PostgreSQL sürücülerini ve ORM'leri burada kullanır. 3. **Alan İzolasyonu:** Alan Varlıkları (Entities) dış kütüphanelerden bağımsız, saf iş mantığı ve Değer Nesneleri (`Email`, `Money`) içerir. 4. **Açılışta Kontrolün Tersine Çevrilmesi:** Uygulama başlangıç noktası (`server.ts` veya DI konteyneri) adaptörü ayağa kaldırır ve kullanım senaryosuna enjekte eder.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Temiz Mimari'de bağımlılıkları yöneten birincil kural nedir?

Kaynak kod bağımlılıkları yalnızca İÇERİYE (yüksek seviyeli iş kurallarına) bakabilir; iç katmanlar dış altyapı katmanlarından tamamen habersiz olmalıdır.
Q2

Bağımlılıkların Tersine Çevrilmesi, çekirdekteki bir kullanım senaryosunun PostgreSQL import etmeden veriyi PostgreSQL'e kaydetmesini nasıl sağlar?

Kullanım senaryosu bir arayüz (Port) tanımlar; altyapı katmanı bu arayüzü uygular (Adaptör) ve çalışma zamanında enjekte edilir.

Temiz Mimari ve Bağımlılıkların Tersine Çevrilmesi Kuralı — Sıkça Sorulan Sorular

Bir geliştirici `@Column()` ve `@ManyToOne()` TypeORM veritabanı anotasyonlarını doğrudan `Order` Alan Varlığı sınıfına ekliyor. Hangi mimari ilke ihlal edilmiştir?

Temiz Mimari Bağımlılık Kuralı: İç alan varlığı artık harici bir veritabanı ORM çatısına sıkı sıkıya bağımlı hale getirilmiştir. Alan varlıkları saf nesneler olmalıdır. Onları ORM dekoratörleriyle kirletmek, iş modelinizi veritabanı kütüphanelerine rehin eder.

Temiz Mimari'de saf alan senaryolarını çalıştıran birim testler neden geleneksel entegrasyon testlerinden 1000 kat daha hızlıdır?

Çünkü veritabanı, Docker veya web sunucusu ayağa kaldırmadan bellek içi sahte repolarla tamamen CPU belleğinde çalışır. İş mantığını altyapıdan izole etmek, tüm iş kurallarını mikrosaniyeler içinde test eden ışık hızında bellek içi testler sağlar.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Temiz Mimari Bağımlılık Kuralı, tüm kaynak kod bağımlılıklarının yalnızca içeriye (yüksek seviyeli iş kurallarına) bakmasını şart koşar; veritabanı veya web protokollerinin çekirdek iş mantığına sızması test edilebilirliği yok eder ve sistemi kilitler.
  • ▸Bağımlılık Kuralı, dış halkaların (altyapı, web, veritabanı) iç halkalara (kullanım senaryoları, alan) bağımlı olmasını, ancak iç halkaların ASLA dış halkalara bağımlı OLMAMASINI şart koşan temel kısıtlamadır.

Yaygın Yanılgılar

  • ✗Ham HTTP `Request` / `Response` nesnelerini veya veritabanı satırlarını doğrudan Alan kullanım senaryolarına parametre geçmek.

Karar Kılavuzu & Önceliklendirme

İş kurallarını doğrudan çatılara (Prisma, Spring, TypeORM) bağlamak, birim testler için veritabanı ayağa kaldırmayı zorunlu kılar, framework güncellemelerini riskli yeniden yazımlara dönüştürür ve altyapı değişimini engeller.

Doğrulanmış Kaynaklar & Referanslar

İlgili Kavramlar

https://tinycto.tv/topics/software-architecturehttps://tinycto.tv/incidentpedia