Go'da CRUD Mimarisi: Anemic vs Rich Models Tartışması

Go geliştiricileri sıkça şu soruyla karşılaşıyor: Backend mimarisinde veri nesnelerini nasıl tasarlamak gerekir? Özellikle diğer dillerden geçen yazılımcılar için bu kararlar kafa karışıklığına yol açabiliyor.

Go'nun felsefi yaklaşımı burada önemli rol oynuyor. Dil, açık ve basit kodu tercih eder; gizlenmiş karmaşıklıktan uzak durur. Bu bağlamda iki ana strateji ortaya çıkıyor.

Anemic Model Yaklaşımı: Struct'lar sadece veri taşıyıcı olarak kalır, davranışlar ayrı fonksiyonlara ve service katmanına yerleştirilir. Örneğin `Product` struct'ı sadece alanları içerir; validasyon ve iş kuralları `ProductService.Validate()` gibi fonksiyonlarda yaşar. Bu yöntem Go'nun "explicit is better than implicit" felsefesine uygun düşer ve test etmeyi kolaylaştırır.

Rich Model Yaklaşımı: Struct'ın private alanları ve receiver metodları (örneğin `(p *Product) Validate()`) olur. Verilerin tutarlılığı nesne içinde garanti edilir. Ancak Go'da bu desen, dil tasarımı gereği, Java veya C# kadar doğal hissedilmez.

Çoğu Go projesi anemic modeli tercih ediyor çünkü bu daha okunur, test edilebilir ve Go kültürüne uygun. Interface'ler ve composition Go'da davranış eklemenin tercih edilen yoludur.

Paket yapısında ise `internal/product/domain` gibi derinlikler sık olsa da, `internal/user/domain/entity/user.go` dosyasından `Product`'a erişim sırasında import yolu açık ve okunaklı kalır. Go, paket adlarını kısa tutmayı önerir; `domain` ve `entity` gibi katmanlar genellikle tek bir paket altında birleştirilir.