Laravel Framework ile birçok proje geliştiriyoruz. Lakin büyük çaplı yani kalabalık projelerde Laravel üzerine geliştirmeler yapılması oldukça zor.
Birçok kesimden şu sözü duymuşsunuzdur: “Laravel kendi yapınızı uygulamanıza imkan vermiyor”. Lakin durum o şekilde değil. Tasarım desenleri ile profesyonel bir sistem geliştirdiğinizde Laravel‘in aksine daha büyük imkan sağladığını görüyorsunuz. Diğer bir şekilde ifade etmek gerekirse, spagetti kodlamayla zaten tasarım desenlerine sahip bir yapı üzerine kendi yapınızı inşa etmek mümkün değil.
Lafı daha fazla uzatmadan konuya geçmek istiyorum yalnız şu hatırlatmayı yapmamda yarar var. Burada bahsedilen büyük ölçek 60-70’ten fazla model sınıflarının olması ve yapının bir çok küçük parçadan oluşmasıdır. Yaptığınız proje eğer küçük veya orta ölçekli ise Laravel’in kendi yapısının üzerine çıkmanıza gerek yok. Bu sizin üretkenliğinizi oldukça düşürecektir.
Laravel’in Kendi Yapısı
Büyük ölçekli yapıda kullanabileceğimiz desenlere geçmeden önce Laravel’in kendi yapısını tekrar gözden geçirelim. Aşağıdaki yapı Laravel 5.6 sürümünden. Bu yapı hakkında kafanıza takılan bir kısım yoksa diğer konu başlığına hızlıca geçiş yapabilirsiniz.
.
├── app
│ ├── Broadcasting
│ ├── Console
│ ├── Events
│ ├── Exceptions
│ ├── Http
│ ├── Jobs
│ ├── Listeners
│ ├── Mail
│ ├── Notifications
│ ├── Policies
│ ├── Providers
│ ├── Rules
│ └── User.php
├── bootstrap
│ ├── app.php
│ └── cache
├── config
├── database
│ ├── factories
│ ├── migrations
│ └── seeds
├── public
├── resources
│ ├── assets
│ ├── lang
│ └── views
├── routes
│ ├── api.php
│ ├── channels.php
│ ├── console.php
│ └── web.php
├── storage
├── vendor
└── tests
/app Dizini
Burada belirtilen app klasörü uygulama kodlarımızın bulunduğu dizindir.
/bootstrap Dizini
Çatımızın asıl başlangıç noktasıdır. Laravel Framework’ün kendi yapısını başlattığı ve cache klasörünü oluşturduğu kısımdır.
/config Dizini
İsminden de anlaşıldığı gibi ayarların tutulduğu dizindir. Ayar bilgileri bu
dizindeki dosyalardan elde edilmektedir. Gizli(Secret) bilgileri de dotenv
aracılığıyla burada sisteme dahil edilmektedir.
/database Dizini
Veritabanı yapısı ile ilgili işlemlerin tutulduğu dizindir. migrations, factories ve seeds burada bulunmaktadır.
/public Dizini
Dış isteklerin yapıldığı başlangıç noktasıdır. Ek olarak isteklerde servis edilecek asset dosyaları (hazırlanmış css, js, resim dosyaları gibi) burada tutuyoruz.
/resources Dizini
resources dizini presentation yani ön tarafta kullanıcıya göstereceğimiz
verileri hazırladığımız kısımdır. views, derlenecek asset dosyaları ve
dil dosyaları örneğin burada tutulur.
/routes Dizini
routes dizini içerisinde herhangi bir ortamdan gelen isteğin nerede
karşılık bulunduracağını belirtiriz. Burada ortamdan kasıt, web isteği
olabildiği gibi websocket istekleri de olabilir.
/storage Dizini
storage dizini içerisinde isminden de anlaşılabildiği gibi saklamak
istediğimiz dosyaları tutmaktayız. Bunların içerisinde framework tarafından
hazırlanan dosyalar(örneğin log) olduğu gibi kendimizin de tutmak istediği
dosyalar(örneğin bir müzik sitesi için müzik dosyaları) da olabilir.
/tests Dizini
PHPUnit ile çalıştırmak istediğimiz testleri bu dizin içerisinde oluşturuyoruz.
/vendor Dizini
Composer bağımlılıklarımızın tutulduğu dizin.
/app/Broadcasting Dizini
Örneğin Websocket üzerinden yaptığımız gerçek zamanlı istekler/etkinlikler burada kontrol altında tutulmaktadır.
/app/Console Dizini
Artisan için oluşturduğunuz komutların tutulduğu dizindir. Bu komutlar tek seferlik işlemlerde kullanılabileceği gibi schedule hazırladığınız zamanlı görevler de olabilir.
/app/Events Dizini
Herhangi bir olay durumunda yaptırmak istediğiniz işlemleri tanımladığınız sınıfları tutan dizindir.
/app/Exceptions Dizini
Uygulamaya özel oluşturduğunuz hata sınıflarını oluşturduğunuz dizindir.
/app/Http Dizini
HTTP istekleriyle ilgili yapılması gerekenleri tutan dizindir. Controller, Middleware ve Requests burada tutulur.
/app/Jobs Dizini
Senkron veya Asenkron olarak tanımladığımız işleri burada tutmaktayız.
/app/Listeners Dizini
Oluşturduğunuz Eventler sonucunda yapılması gereken işlemleri burada
tanımlamaktasınız. Örneğin UserLicenseFinished etkinliği(event) sonucunda
TerminateUser ve SendTerminatedUserEmail listenerlarını burada
oluşturabilirsiniz.
/app/Mail Dizini
Uygulama tarafından gönderilecek e-postaları inşa edecek sınıfları bu dizinde tutmaktayız.
/app/Notifications Dizini
Çeşitli bildirim gönderme ortamları(SMS, E-Posta ve Slack gibi) için bildirimleri inşa ettiğimiz sınıfları oluşturduğumuz dizindir.
/app/Policies Dizini
Herhangi bir işlem için (Örneğin giriş veya api isteği) izin kontrol sınıflarını oluşturduğunuz dizindir.
/app/Providers Dizini
ServiceProviderları tanımladığınız dizindir.
/app/Rules Dizini
Validate etmek istediğiniz veriler için oluşturduğunuz sınıfları tutan dizindir.
Biraz Daha Serbest
Orta ölçekli bir projede bu yapının üzerine ufak değişiklikler elbetteki yapıyoruz. Örneğin Models isminde bir namespace üzerinde model sınıfları ayrı bir şekilde tutuyoruz. Ek olarak Repositories ve Services de ekliyoruz.
Repository Pattern
Repository desenini tek bir makalede incelemek haksızlık olacaktır. Temel anlamda veri üzerinde işlem yapan kısım ile veriye erişen kısmın ayrılması diyebiliriz.
Buradaki Services kısmı ise Repository ile haberleşen kısmın da uygulama katmanından ayıran kısımdır. Bir örnek ile ilerlemek daha iyi olacaktır.
namespace App/Repositories;
interface UserInterface {
public function getUserById($userId);
public function getUserByUsername($username);
}
namespace App/Repositories;
class UserRepository implements UserInterface {
protected $model;
public function __construct(Model $model) {
$this->model = $model;
}
public function getUserById($userId) {
return $this->model->find($userId);
}
public function getUserByUsername($username) {
return $this->model->where('username', strtolower($username))->first();
}
}
namespace App/Services;
class UserService {
protected $repository;
public function __construct(UserInterface $repository){
$this->repository = $repository;
}
public function getUser($user) {
if(is_numeric($user))
return $this->repository->getUserById($user);
else
return $this->repository->getUserByUsername($user);
}
}
Bu örnek yapıda Service ve Repository kullanmış olduk. (Yapının çalışması için iki yapı için de ServiceProvider sınıflarını hazırlamanız gerekmektedir.)
Bu yapıda hiçbir sorun yok. Oldukça organize ve güzel bir yapı çıkmış oluyor. Lakin belirttiğim gibi orta ölçekli proje için uygun olacaktır. Büyük ölçekli projede bu yapı hayat kurtarmayacaktır.
Örneğin bu yapının sonunda Models dizinimize bakalım:
.
├── AklimaBaskaModelGelmedi.php
├── AnotherAnotherModel.php
├── AnotherModel.php
├── Comment.php
├── Gallery.php
├── Like.php
├── Note.php
├── Photo.php
├── Profile.php
├── Transaction.php
└── User.php
Uygulamamız üzerine eklediğimiz modüllerle bu Models dizini oldukça büyüyecektir. Bir alternatif olarak bu modülleri ayrı namespace üzerinde tutabilirsiniz. Lakin bir süre sonra bu da kurtarmayacaktır.
Aklıma Bir Şeyler Geliyor Ama?
Bu aşamada aklınıza gelen yol büyük ihtimal, “Hadi o zaman projeyi microservislere ayıralım” olacaktır. Lakin bu iş o kadar kolay değil. Oluşturduğumuz büyük ölçekli yapıyı küçük küçük parçalara ayırmak oldukça zahmetli olacaktır. Temel olarak uygulayacağınız yol şu olur büyük ihtimal; Bir parçayı al ufak bir mikroservis uygulaması haline getir (apayrı bir proje olmuş oldu) ve uygulama üzerindeki projede gelen isteği bu mikroservise yönlendir. Bütün bu uğraş sonucunda da kazandığınız (!) sorunlar:
- Herhangi bir değişiklikte hata yapmanız muhtemel
- Yeni bir geliştirici anlamakta çok fazla zorlanacak ve ayrı ayrı parçalara bakmak zorunda kalacak.
- Çok fazla dosya
- Yeniden bir çözüm arayışı
Bir Seçenek Daha Var O da “Domain Driven Design” Mı Dersin?
Elbette tek bir çözüm yolu yok. Yukarda bahsettiğim yapıları daha da geliştirebilir veya HMVC yapısına geçiş yapabilirsiniz. Her desenin + ve - leri var.
DDD’yi özetlemek gerekirse:
- Application yani uygulama: Controller, Middleware, Route
- Domain yani ana işi yapan işlev: Model, Repository, Policy vs.
- Infrastructure yani servisler: Email, Notification, Logging vs.
- Interface yani görünüş, gözüken kısım: Views, Lang, Assets nam-ı diğer Resources
Peki bu yapıda örnek Laravel dizini nasıl olabilir:
.
├── app
│ ├── Account (Domain)
│ │ ├── AccessControlLists.php
│ │ ├── Auth.php
│ │ ├── Console
│ │ ├── Jobs
│ │ ├── Listeners
│ │ ├── Repositories
│ │ ├── Models
│ │ └── Validators
│ ├── Http (Application)
│ ├── Infrastructure
│ │ ├── Events
│ │ └── Exceptions
│ ├── Gallery (Domain)
│ └── Post (Domain)
├── bootstrap
│ ├── app.php
│ └── cache
├── config
├── database
│ ├── factories
│ ├── migrations
│ └── seeds
├── public
├── resources (Interface)
│ ├── assets
│ ├── lang
│ └── views
├── routes
│ ├── api.php
│ ├── channels.php
│ ├── console.php
│ └── web.php
├── storage
├── vendor
└── tests
Fark edebileceğiniz üzere DDD’de sadece namespace eklemekten başka bir durum yok.
Sen Pala Vere Bırak Sonuç Göster
Sonuç yapıyı göstermek istersek şöyle bir yapı uygun olacaktır:
.
├── app
│ ├── Account
│ │ ├── AccessControlLists.php
│ │ ├── Auth.php
│ │ ├── Console
│ │ ├── Events
│ │ ├── Exceptions
│ │ ├── Jobs
│ │ ├── Listeners
│ │ ├── Models
│ │ ├── Repositories
│ │ └── Validators
│ ├── Gallery
│ ├── Http
│ │ ├── Controllers
│ │ └── Middleware
│ ├── Post
│ └── Providers
├── bootstrap
│ ├── app.php
│ └── cache
├── config
├── database
│ ├── factories
│ ├── migrations
│ └── seeds
├── public
├── resources
│ ├── assets
│ ├── lang
│ └── views
├── routes
│ ├── api.php
│ ├── channels.php
│ ├── console.php
│ └── web.php
├── storage
├── vendor
└── tests
Elbette çok büyük ölçekte bir Laravel Uygulamasında bu yapı da yeterli olmayacaktır.
Şimdi bir senaryo kuralım. Projemizde Authentication kısmı mikroservis
yapılması gerektiği ile ilgili bir karar alındı. Bu durumda bu yapıdaki bir
projede tek yapılması gereken Account (domain) dizininin mikroservis olarak
ayrılması. Komple bir değişiklik yapmaya gerek kalmadan sadece o modülü
mikroservis çok rahat yapabiliriz. Çünkü domain dışındaki diğer tüm sınıflar
AccessControlLists ve Auth sınıflarını biliyor ve kullanıyor. Bunları
tutmak yeterli olacaktır. Mikroservisi hazırladıktan sonra ana projemizdeki
dizin yapısı şu şekilde olacaktır:
.
├── app
│ ├── Account
│ │ ├── AccessControlLists.php
│ │ └── Auth.php
│ ├── Gallery
│ ├── Http
│ │ ├── Controllers
│ │ └── Middleware
│ ├── Post
│ └── Providers
├── bootstrap
│ ├── app.php
│ └── cache
├── config
├── database
│ ├── factories
│ ├── migrations
│ └── seeds
├── public
├── resources
│ ├── assets
│ ├── lang
│ └── views
├── routes
│ ├── api.php
│ ├── channels.php
│ ├── console.php
│ └── web.php
├── storage
├── vendor
└── tests
Gördüğünüz gibi uygulama kodlarımız içerisinde bir değişiklik yapmadan
modül olarak ayırmış ve mikroservis haline getirmiş olduk. Buradaki
AccessControlLists ve Auth mikroservisimizle haberleşecektir.
Dikkat edilmesi gereken kısım ise, bu gibi senaryolara sahip olabileceğimiz
için Domain içerisindeki haberleşen Service sınıflarımızın temel veri
türlerini kullanması gerektiğidir. Örneğin, array, string, int ve
boolean gibi. Herhangi bir sınıf belirtmeniz ayırma işlemi sonucunda sorun
çıkartacaktır. Çünkü o sınıfı tanımıyor ve bilmiyor olacaktır.
Bitiş
Yazı içerisinde elbetteki yanlışlarım olmuş olabilir. Yazıyı düzenleyerek hataları gidererek daha iyi bir makale haline getirebiliriz. Eklenmesini istediğiniz kısımları da yine aynı şekilde düzenleyerek pull request atabilirsiniz.
