Spring Boot Internal Mechanics

Mini sözlük: Aynı dili konuşalım

Spring anlatımında bazı kelimeler çok sık geçer. Bu kelimeleri en başta sadeleştirirsek, birazdan göreceğimiz iç mekanikler çok daha rahat oturur.

Önce büyük resmi kuralım

Spring Boot’un temel vaadi şudur: “Sen business koduna odaklan, ben uygulamayı ayağa kaldırmak için gereken standart parçaları hazırlarım.”

Bir web uygulaması yazmak aslında sadece controller yazmak değildir. HTTP request’i karşılayacak bir altyapı, request’i doğru method’a yönlendirecek bir mapping sistemi, JSON’u Java objesine çevirecek converter’lar, validation mekanizması, hata cevabı üretimi, embedded server, configuration okuma, dependency injection, bean lifecycle ve daha birçok parça gerekir. Spring Boot bu parçaların çoğunu yaygın ve güvenli default’larla hazırlar.

Başlangıç seviyesinde bu “kolaylık” olarak görülür. Senior seviyede ise mesele biraz değişir: Spring Boot’un bizim yerimize ne oluşturduğunu, neden oluşturduğunu, ne zaman oluşturmadığını ve gerektiğinde nasıl override edeceğimizi bilmemiz gerekir. Çünkü production problemleri genellikle “kod yazmadığım halde bir şey devreye girdi” veya “beklediğim bean neden oluşmadı?” sorularıyla başlar.

Auto Configuration nedir?

Spring Boot’un “sen yazmadan ben default bean’i oluştururum” mekanizmasıdır.

En basit haliyle şöyle düşünebiliriz: Sen projeye bir özellik eklersin, Spring Boot da o özelliğin çalışması için genelde gereken altyapı bean’lerini hazırlar. Örneğin projeye spring-boot-starter-web eklediğinde Spring Boot “bu uygulama HTTP request alacak” sonucuna varır. Bu durumda embedded Tomcat, DispatcherServlet, JSON dönüşümü için Jackson, controller method mapping altyapısı ve default hata yönetimi gibi parçaları sen tek tek tanımlamadan kurar.

Bu mekanizmanın çözdüğü problem tekrar eden konfigürasyondur. Spring Boot öncesinde her projede benzer altyapı ayarları tekrar tekrar yazılırdı. Bu hem zaman kaybettirir hem de ekipler arasında tutarsızlık oluştururdu. Spring Boot burada “yaygın senaryolar için mantıklı default’ları ben sağlayayım, sen sadece farklı davranmasını istediğin yerleri değiştir” yaklaşımını kullanır.

spring-boot-starter-web eklenince neler olabilir?

Bir tık derin: Spring Boot karar verirken neye bakar?

Auto configuration rastgele çalışmaz. Spring Boot, bazı koşulları değerlendirerek hangi configuration class’larının aktif olacağına karar verir. Bu sayede hem default davranış sağlanır hem de developer’ın açıkça yazdığı bean’ler ezilmez.

@Bean
@ConditionalOnMissingBean
public ObjectMapper objectMapper() {
    return new ObjectMapper();
}

// Anlamı:
// Uygulamada ObjectMapper bean’i yoksa default bir ObjectMapper oluştur.
// Ama developer kendi ObjectMapper bean’ini yazdıysa ona dokunma.

MiniBank bağlantısı

MiniBank geliştikçe Spring Boot’un default MVC, JSON, validation, JPA, security ve actuator davranışlarından faydalanacağız. İlerleyen aşamalarda ortak audit/logging/tracing gibi konular için kendi MiniBank starter mantığımızı da düşünebiliriz. Bu modülde amaç bu mekanizmanın temelini okumayı öğrenmek.

Component Scanning nasıl çalışır?

Component scanning, Spring’in belirli paketleri tarayıp annotation’lı class’ları bean olarak keşfetmesidir.

Normal Java’da bir class yazmak, o class’ın uygulama tarafından otomatik kullanılacağı anlamına gelmez. Bir objenin oluşması için ya sen new ile oluşturursun ya da bir framework onu oluşturur. Spring tarafında @Service, @Repository, @Controller, @Configuration gibi annotation’lar Spring’e “bu class uygulama context’inde yönetilmeli” sinyali verir.

@SpringBootApplication içinde @ComponentScan vardır. Varsayılan davranış şudur: application class’ın bulunduğu paketten başlar ve alt paketleri tarar. Bu nedenle ana application class’ı genellikle projenin root package’ında durmalıdır.

com.definex.minibank
├── MiniBankApplication.java       ← @SpringBootApplication burada
├── account
│   ├── AccountService.java        ← taranır
│   └── AccountRepository.java     ← taranır
├── customer
│   ├── CustomerService.java       ← taranır
│   └── CustomerRepository.java    ← taranır
├── transaction
│   └── TransactionService.java    ← taranır
└── config
    └── WebConfig.java             ← taranır

ApplicationContext nasıl oluşur?

ApplicationContext, Spring’in runtime container’ıdır. Bean’leri oluşturur, saklar, birbirine bağlar ve yaşam döngüsünü yönetir.

Saf Java’da objeleri çoğunlukla biz oluştururuz. Örneğin new AccountService(new AccountRepository()) gibi bir zincir kurarız. Küçük uygulamalarda bu yönetilebilir görünebilir, ama gerçek projede onlarca service, repository, controller, configuration ve external client olduğunda obje yaratma sırası, dependency ilişkileri ve lifecycle karmaşıklaşır.

Spring bu kontrolü üzerine alır. Sen class’ları ve dependency ilişkilerini tanımlarsın; Spring hangi bean’in önce oluşacağını, hangi bean’in hangi constructor’a verileceğini, hangi profile’a göre hangi bean’in aktif olacağını ve uygulama kapanırken hangi cleanup adımlarının çalışacağını yönetir. Bu yüzden Spring dünyasında “kontrol framework’e geçti” deriz. Bu, IoC’nin pratik karşılığıdır.

Production’da bu bilgi çok değerlidir. Uygulama neden başlamadı, bean neden bulunamadı, belirli bir configuration neden devreye girdi, yanlış profile mı aktif oldu, startup neden yavaşladı gibi soruların çoğu ApplicationContext oluşum süreciyle ilgilidir.

MiniBank bağlantısı

MiniBank içindeki AccountService, CustomerService, repository’ler, controller’lar, configuration class’ları ve ileride ekleyeceğimiz security, JPA, actuator parçaları bu context içinde yaşayacak. Bu yüzden ilk case’te context’in bean’leri nasıl keşfettiğini ve oluşturduğunu küçük servis katmanı üzerinden gözlemleyeceğiz.

Bean lifecycle

Bean lifecycle, Spring’in bir bean’i doğumundan kapanışına kadar yönettiği süreçtir.

Bir bean sadece “oluşturulmuş obje” değildir. Spring önce instance’ı oluşturur, dependency’leri bağlar, gerekli initialization hook’larını çalıştırır, bazı bean’leri proxy ile sarabilir ve uygulama kapanırken cleanup hook’larını çağırabilir. Bu akış özellikle startup işlemleri, cache warmup, health check hazırlığı, resource cleanup, AOP ve transaction davranışlarını anlamak için önemlidir.

Basit kural şu: Constructor, objenin zorunlu dependency’lerini almak içindir. Dependency’ler bağlandıktan sonra yapılması gereken başlatma işleri için @PostConstruct daha uygun bir noktadır. Uygulama kapanırken kaynakları temizlemek için @PreDestroy kullanılabilir.

@Service
public class StartupReporter {

    public StartupReporter() {
        System.out.println("1 - constructor çalıştı");
    }

    @PostConstruct
    public void init() {
        System.out.println("2 - dependency injection sonrası init çalıştı");
    }

    @PreDestroy
    public void destroy() {
        System.out.println("3 - uygulama kapanırken cleanup çalıştı");
    }
}

Dependency Injection Best Practices

Dependency Injection, bir class’ın ihtiyaç duyduğu objeleri kendi oluşturması yerine dışarıdan almasıdır.

Bu yaklaşım class’ları daha test edilebilir, daha esnek ve daha düşük bağımlı hale getirir. Örneğin AccountService, repository’yi kendi içinde new ile oluşturursa testte onu değiştirmek zorlaşır. Ama repository constructor’dan verilirse testte fake veya mock repository vermek kolaylaşır.

Neden constructor injection?

@Service
public class AccountService {

    @Autowired
    private AccountRepository accountRepository;

    // Dependency gizli.
    // final kullanılamaz.
    // Spring olmadan test zorlaşır.
}

@Service
public class AccountService {

    private final AccountRepository accountRepository;

    public AccountService(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }
}

Setter injection tamamen kötü değildir; özellikle optional dependency gibi nadir durumlarda kullanılabilir. Ama business service, repository, controller ve application service gibi ana bileşenlerde varsayılan tercih constructor injection olmalıdır. MiniBank boyunca bu standardı kullanacağız.

Bu modülden akılda kalması gerekenler