Service Layer Pattern

Service Layer Modeli, business logicnı özel hizmet sınıfları halinde düzenlemek için kullanılan bir yazılım tasarım modelidir. Hizmet katmanı, önemli uygulama kurallarını denetleyicilerin, modellerin, rotaların veya görünümlerin içine yerleştirmek yerine iş iş akışları ve uygulama işlemleri için açık bir yer sağlar.

Bu model genellikle nesne yönelimli uygulamalarda, PHP projelerinde, Laravel uygulamalarında, Symfony sistemlerinde, APIs, kurumsal yazılımlarda ve clean architecture'da kullanılır. Geliştiricilerin denetleyicileri ince tutmasına, modellere odaklanmasına ve business logicnın test edilmesi ve bakımının daha kolay olmasına yardımcı olur.

Giriş

Bu OOP ve Design Patterns serisinin önceki makalelerinde MVC Modeli, Repository Pattern, Dependency Injection, Facade Pattern, Command Pattern, Observer Pattern, Strategy Pattern ve diğer birçok yazılım tasarımı konsepti.

Service Layer Modeli özellikle önemlidir çünkü business logic yanlış katmana yerleştirildiğinde birçok uygulama karmaşık hale gelir. Denetleyiciler çok büyüyor, modeller aşırı yükleniyor ve database sorguları iş akışı kurallarıyla karışıyor.

Hizmet katmanı, kullanıcı kaydı, ödeme işleme, rapor oluşturma, abonelik yönetimi, ödeme işleme, dosya içe aktarma ve bildirim iş akışları gibi uygulamaya özel iş operasyonları için özel bir katman oluşturarak bu sorunu çözer.

Service Layer Deseni Nedir?

Service Layer Modeli, business logicnı ve uygulama iş akışlarını hizmet sınıflarının içine yerleştiren bir tasarım modelidir. Bir hizmet sınıfı genellikle belirli bir işlemi tamamlamak için modelleri, depoları, harici APIs'yu, doğrulayıcıları, olayları, işleri ve diğer bileşenleri koordine eder.

Basit bir ifadeyle, bir hizmet katmanı şu soruyu yanıtlar: Uygulamanın ana business logic nerede yaşamalı?

Örneğin, bir CheckoutService sepeti doğrulayabilir, indirimleri hesaplayabilir, ödemeyi işleyebilir, sipariş oluşturabilir, stoğu azaltabilir, fatura oluşturabilir ve onay bildirimleri gönderebilir. Bu iş akışı genellikle bir denetleyicinin veya görünümün içinde yer almamalıdır.

Service Layer Modeli Neden Önemlidir?

Service Layer Modeli önemlidir çünkü business logic genellikle zamanla gelişir. İlk başta bir denetleyici yöntemi yalnızca birkaç satır içerebilir. Daha sonra aynı yöntem validation, database erişimini, ödeme mantığını, e-posta göndermeyi, olay göndermeyi ve hata işlemeyi içerebilir.

Bu mantık denetleyicinin içinde kaldığında denetleyicinin okunması ve test edilmesi zorlaşır. Bir hizmete taşındığında denetleyici küçülür ve iş akışı yeniden kullanılabilir hale gelir.

Hizmet katmanı, istek işlemeyi iş davranışından ayırarak sürdürülebilirliği artırır.

Service Layer Olmayan Sorun

Doğrudan kullanıcı kaydını yöneten bir denetleyici düşünün:

class RegisterController
{
    public function register(Request $request)
    {
        if (User::where('email', $request->email)->exists()) {
            throw new RuntimeException('Email already exists.');
        }

        $user = User::create([
            'name' => $request->name,
            'email' => $request->email,
            'password' => password_hash($request->password, PASSWORD_BCRYPT),
        ]);

        Profile::create([
            'user_id' => $user->id,
            'bio' => '',
        ]);

        Mail::to($user->email)->send(new WelcomeMail($user));

        event(new UserRegistered($user));

        return $user;
    }
}

Bu denetleyici çok fazla şey yapıyor. Benzersizliği kontrol eder, bir kullanıcı oluşturur, bir parola karma işlemi yapar, bir profil oluşturur, e-posta gönderir ve bir etkinlik gönderir.

API, yönetici paneli, CLI komutu veya içe aktarma işlemi gibi başka bir yerden kullanıcı kaydı gerekiyorsa mantık kopyalanabilir. Bir hizmet katmanı bu çoğaltmayı önler.

Service Layer ile Çözüm

İş mantığı özel bir hizmete taşınabilir:

class UserRegistrationService
{
    public function register(array $data): User
    {
        if (User::where('email', $data['email'])->exists()) {
            throw new RuntimeException('Email already exists.');
        }

        $user = User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => password_hash($data['password'], PASSWORD_BCRYPT),
        ]);

        Profile::create([
            'user_id' => $user->id,
            'bio' => '',
        ]);

        Mail::to($user->email)->send(new WelcomeMail($user));

        event(new UserRegistered($user));

        return $user;
    }
}

Denetleyici daha temiz hale gelir:

class RegisterController
{
    public function __construct(
        private UserRegistrationService $registrationService
    ) {
    }

    public function register(Request $request)
    {
        return $this->registrationService->register($request->all());
    }
}

Artık denetleyici isteği yönetirken, hizmet de iş akışını yönetir.

Service Layer'nun Ana Sorumlulukları

Hizmet katmanı, uygulama iş akışlarından ve iş operasyonlarından sorumludur. Bir kullanım senaryosunu tamamlamak için genellikle birkaç nesneyi koordine eder.

Ortak sorumluluklar şunları içerir:

• İş iş akışlarının yürütülmesi.

• Repositoryları ve modelleri koordine etmek.

• Harici APIs veya adaptörlerin çağrılması.

• İş kurallarını uygulamak.

• Etkinliklerin veya işlerin gönderilmesi.

• İşlemleri yönetmek.

• Bildirim servislerinin aranması.

• Verilerin uygulama işlemleri için hazırlanması.

Bir hizmet, yalnızca rastgele bir collection yardımcı yöntem değil, anlamlı uygulama davranışını temsil etmelidir.

Service Layer'da Ne Olmamalı?

Hizmet katmanı her kod parçası için çöplük haline gelmemelidir. Repositorylara ait olan ilgisiz yardımcı program işlevlerini, sunum mantığını, HTML oluşturmayı veya düşük düzeyli database ayrıntılarını içermemelidir.

Örneğin, veri erişiminden bir veri havuzu sorumluysa, hizmet doğrudan karmaşık SQL sorguları oluşturmamalıdır. Ayrıca görünümler için HTML biçimlendirilmemelidir çünkü sunum görünüm katmanına aittir.

İyi bir hizmet katmanı, iş kullanım senaryolarına ve uygulama iş akışlarına odaklanır.

Service Layer ve MVC Modeli

MVC bir uygulamayı Model, Görünüm ve Denetleyici olarak ayırır. Ancak MVC tek başına karmaşık business logicnın nereye gitmesi gerektiğini her zaman açıklamaz.

Küçük uygulamalarda kontrolörler modelleri doğrudan çağırabilir. Ancak daha büyük uygulamalarda, tüm business logicnı kontrolörlerin veya modellerin içine yerleştirmek, yağ kontrolörleri ve yağ modelleri oluşturabilir.

Service Layer Modeli, denetleyiciler ile veri/model mantığı arasına kullanışlı bir katman ekler. Denetleyiciler hizmetleri arar, hizmetler iş akışlarını yürütür ve depolar veya modeller veri erişimini yönetir.

Service Layer'lu İnce Denetleyiciler

Hizmet katmanının en büyük yararı denetleyicileri ince tutmaktır. İnce denetleyici girdiyi alır, işi bir hizmete devreder ve bir yanıt döndürür.

class CheckoutController
{
    public function __construct(
        private CheckoutService $checkoutService
    ) {
    }

    public function store(Request $request)
    {
        $order = $this->checkoutService->checkout(
            $request->user(),
            $request->all()
        );

        return response()->json($order);
    }
}

Kontrolör her ödeme adımını bilmiyor. İşlemi CheckoutService'e devreder.

Service Layer ve Repository Pattern

Service Layer Deseni ve Repository Pattern sıklıkla birlikte kullanılır ancak aynı değildir.

Bir depo veri erişimini yönetir. Verileri alır, kaydeder, günceller ve siler. Bir hizmet, business logicnı ve iş akışlarını yönetir.

Örneğin, UserRepository bir kullanıcıyı e-posta yoluyla bulabilir. UserRegistrationService, e-postanın var olup olmadığını kontrol edebilir, şifreyi karıştırabilir, kullanıcıyı oluşturabilir, bir e-posta gönderebilir ve bir etkinlik gönderebilir.

Repositorylar “verilere nasıl erişiriz?” sorusunun cevabını verir. Hizmetler "Hangi ticari operasyon gerçekleşmeli?" sorusunu yanıtlıyor.

PHP'da Repository Örneğiyle Hizmet

interface UserRepositoryInterface
{
    public function findByEmail(string $email): ?User;

    public function create(array $data): User;
}

class UserRegistrationService
{
    public function __construct(
        private UserRepositoryInterface $users,
        private PasswordHasher $passwordHasher,
        private WelcomeEmailService $welcomeEmail
    ) {
    }

    public function register(array $data): User
    {
        if ($this->users->findByEmail($data['email'])) {
            throw new RuntimeException('Email already exists.');
        }

        $user = $this->users->create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => $this->passwordHasher->hash($data['password']),
        ]);

        $this->welcomeEmail->send($user);

        return $user;
    }
}

Hizmet, bağımlılıkları koordine eder ve iş kurallarını uygular. Repository, kullanıcı veri erişimini yönetir.

Service Layer ve Dependency Injection

Dependency Injection, Service Layer Modeli'nde çok önemlidir. Hizmetler genellikle depolara, bağdaştırıcılara, harici APIs'ya, stratejilere, günlükçülere, olay göndericilere ve diğer hizmetlere bağlıdır.

Hizmet içinde bağımlılıklar oluşturmak yerine, bunların yapıcı aracılığıyla enjekte edilmesi gerekir.

class ReportService
{
    public function __construct(
        private ReportRepositoryInterface $reports,
        private PdfExporterInterface $pdfExporter,
        private FileStorageInterface $storage
    ) {
    }
}

Bu, hizmetlerin test edilmesini ve değiştirilmesini kolaylaştırır.

Service Layer ve İşlemler

Birçok hizmet yöntemi, birlikte başarılı veya başarısız olması gereken birden çok database işlemini gerçekleştirir. Bu durumlarda hizmet katmanı işlemleri yönetmek için iyi bir yerdir.

Örneğin, ödeme bir sipariş oluşturabilir, sipariş öğeleri oluşturabilir, stoğu azaltabilir ve ödemeyi kaydedebilir. Bir adım başarısız olursa tüm işlemin geri alınması gerekebilir.

class CheckoutService
{
    public function checkout(User $user, array $cartData): Order
    {
        return DB::transaction(function () use ($user, $cartData) {
            $order = $this->orders->create($user, $cartData);

            $this->inventory->decreaseStock($cartData);
            $this->payments->charge($order);
            $this->invoices->create($order);

            return $order;
        });
    }
}

Hizmet, tüm iş akışını anladığı için işlemi koordine eder.

Gerçek Dünyadan Örnek: Ödeme Hizmeti

Ödeme, birkaç iş adımı içerdiğinden Service Layer Modeli'nin güçlü bir örneğidir.

class CheckoutService
{
    public function __construct(
        private CartValidator $cartValidator,
        private DiscountService $discountService,
        private OrderRepositoryInterface $orders,
        private PaymentGatewayInterface $paymentGateway,
        private InventoryService $inventoryService,
        private InvoiceService $invoiceService,
        private EventDispatcherInterface $events
    ) {
    }

    public function checkout(User $user, Cart $cart): Order
    {
        $this->cartValidator->validate($cart);

        $discount = $this->discountService->calculate($user, $cart);

        $order = $this->orders->createFromCart($user, $cart, $discount);

        $this->paymentGateway->charge($order);
        $this->inventoryService->decreaseStock($cart);
        $this->invoiceService->generate($order);

        $this->events->dispatch(new OrderPlaced($order));

        return $order;
    }
}

Bu hizmet tam bir iş kullanım durumunu temsil eder. Denetleyicinin yalnızca ödemeyi araması gerekir.

Gerçek Dünyadan Örnek: Rapor Oluşturma Hizmeti

Rapor oluşturma genellikle veri alımını, biçimlendirmeyi, dışa aktarmayı, depolamayı ve bildirimi içerir.

class ReportGenerationService
{
    public function __construct(
        private ReportRepositoryInterface $reports,
        private ReportFormatter $formatter,
        private PdfExporterInterface $exporter,
        private FileStorageInterface $storage
    ) {
    }

    public function generateMonthlyReport(string $month): string
    {
        $data = $this->reports->getMonthlyData($month);
        $formatted = $this->formatter->format($data);
        $pdf = $this->exporter->export($formatted);

        return $this->storage->save($pdf);
    }
}

Bu, rapor oluşturma mantığını denetleyicilerin dışında tutar ve iş akışını yeniden kullanılabilir hale getirir.

Gerçek Dünyadan Örnek: Dosya İçe Aktarma Hizmeti

Dosya içe aktarma, başka bir yaygın hizmet katmanı kullanım durumudur. validation, ayrıştırma, eşleme, database ekleme, günlüğe kaydetme ve hata işlemeyi içerebilir.

class UserImportService
{
    public function __construct(
        private FileValidator $fileValidator,
        private CsvParser $csvParser,
        private UserRepositoryInterface $users,
        private ImportLogger $logger
    ) {
    }

    public function import(string $filePath): int
    {
        $this->fileValidator->validate($filePath);

        $rows = $this->csvParser->parse($filePath);
        $count = 0;

        foreach ($rows as $row) {
            $this->users->create([
                'name' => $row['name'],
                'email' => $row['email'],
            ]);

            $count++;
        }

        $this->logger->log('Imported users: ' . $count);

        return $count;
    }
}

Bu hizmet, içe aktarma iş akışını merkezileştirir ve denetleyicilerden, komutlardan veya işlerden yeniden kullanılabilir olmasını sağlar.

Laravel'da Service Layer

Laravel, geliştiricileri bir hizmet katmanı kullanmaya zorlamaz ancak birçok orta ve büyük Laravel projesi bundan yararlanır. Hizmetler, proje stiline bağlı olarak app/Services, app/Actions veya app/UseCases gibi klasörlere yerleştirilebilir.

Bir Laravel denetleyicisi, yapıcı veya yöntem enjeksiyonu aracılığıyla bir hizmeti enjekte edebilir:

class UserController extends Controller
{
    public function __construct(
        private UserRegistrationService $registration
    ) {
    }

    public function store(StoreUserRequest $request)
    {
        $user = $this->registration->register($request->validated());

        return redirect()->route('users.show', $user);
    }
}

Denetleyici validation isteğini ve yanıtını yönetir. Hizmet, kayıt iş akışını yönetir.

Form Talebi ile Laravel Hizmeti

Laravel Form İstekleri hizmet sınıflarıyla iyi çalışır. Form İsteği girişi doğrular ve hizmet, doğrulanan verileri kullanır.

public function store(StoreOrderRequest $request)
{
    $order = $this->checkoutService->checkout(
        $request->user(),
        $request->validated()
    );

    return response()->json($order);
}

Bu, validation'yu iş iş akışından ayrı tutar. Servis temiz veri alır ve işlemi gerçekleştirir.

Symfony'da Service Layer

Symfony, hizmet odaklı mimariyi güçlü bir şekilde teşvik eder. Çoğu business logic genellikle bağımlılık enjeksiyon kapsayıcısında kayıtlı hizmetlere yerleştirilir.

Bir Symfony denetleyicisi, yapıcı enjeksiyonu veya yöntem enjeksiyonu yoluyla bir hizmet alabilir:

class RegistrationController extends AbstractController
{
    public function __construct(
        private UserRegistrationService $registration
    ) {
    }

    public function register(Request $request): Response
    {
        $user = $this->registration->register($request->request->all());

        return $this->json($user);
    }
}

Bu, Symfony'nun denetleyicileri küçük tutma ve hizmetleri uygulama mantığı için kullanma felsefesine uygundur.

Service Layer vs Facade Pattern

Service Layer Deseni ve Facade Pattern benzer görünebilir çünkü her ikisi de çeşitli nesneleri koordine eden basit bir yöntem sağlayabilir. Ancak onların odak noktası farklıdır.

Hizmet katmanı, business logicnı ve uygulama kullanım durumlarını düzenler. Bir cephe, karmaşık bir alt sisteme basitleştirilmiş bir arayüz sağlar.

Örneğin CheckoutService bir iş operasyonunu temsil ettiğinden bir hizmet katmanı sınıfıdır. ReportFacade, birden fazla raporlama alt sistemi sınıfının karmaşıklığını gizliyorsa bir görüntü olabilir.

Uygulamada, bir hizmet bazen bir cephe gibi davranabilir, ancak tasarımın amacı önemlidir.

Service Layer vs Denetleyici

Bir denetleyici, HTTP isteklerini ve yanıtlarını yönetir. İstek verileri, kimlik doğrulama bağlamı, yönlendirme, yönlendirmeler ve yanıt formatları hakkında bilgi sahibi olmalıdır.

Bir hizmet, business logicnı ve iş akışlarını yönetir. HTTP'ye özgü ayrıntılara büyük ölçüde bağlı olmamalıdır.

Bu ayırma faydalıdır çünkü aynı hizmet web denetleyicisi, API denetleyicisi, konsol komutu, sıraya alınmış iş veya test senaryosu gibi farklı giriş noktalarından kullanılabilir.

Service Layer ve Model

Bir model, verileri ve etki alanı davranışını temsil eder. Birçok çerçevede modeller database tablolarına da bağlanır.

Bir hizmet, birden fazla modeli ve diğer hizmetleri içerebilecek bir uygulama işlemini veya iş akışını temsil eder.

Örneğin bir Sipariş modeli, toplamının nasıl hesaplanacağını biliyor olabilir. Ancak bir CheckoutService, validation sepetini, ödemeyi, envanteri, fatura oluşturmayı ve sipariş onayını koordine edebilir.

Modeller kendileriyle ilgili davranışları içermeli, hizmetler ise daha büyük iş akışlarını koordine etmelidir.

Service Layer vs Aksiyon Sınıfları

Bazı projeler geleneksel hizmet sınıfları yerine eylem sınıflarını kullanır. Bir eylem sınıfı genellikle CreateUserAction, PlaceOrderAction veya GenerateInvoiceAction gibi belirli bir kullanım durumunu temsil eder.

Bu, hizmet katmanının daha odaklanmış bir versiyonu olarak görülebilir. Pek çok yöntem içeren büyük bir UserService yerine, geliştiriciler her işlem için ayrı eylem sınıfları oluşturur.

Her iki yaklaşım da geçerlidir. En iyi seçim projenin büyüklüğüne, ekip stiline ve karmaşıklığa bağlıdır.

Service Layer ve Temiz Mimari

clean architecture'da hizmet katmanı genellikle uygulama katmanına veya kullanım senaryosu katmanına benzer. Uygulamaya özel kurallar içerir ve etki alanı nesnelerini ve altyapı arayüzlerini koordine eder.

Hizmet, veri havuzu arayüzleri, ödeme ağ geçidi arayüzleri ve bildirim arayüzleri gibi soyutlamalara bağlı olmalıdır. Beton uygulamaları dışarıdan enjekte edilmelidir.

Bu, iş iş akışını çerçevelerden, databases'dan ve harici APIs'dan bağımsız tutar.

Service Layer ve Test

Hizmet katmanı, business logicnın tam bir HTTP isteği çalıştırılmadan test edilebilecek sınıflara yerleştirilmesi nedeniyle testi geliştirir.

Örneğin bir CheckoutService, sahte depolar, sahte ödeme ağ geçitleri ve sahte envanter hizmetleriyle test edilebilir. Bu, testleri daha hızlı ve daha odaklı hale getirir.

$checkoutService = new CheckoutService(
    new FakeCartValidator(),
    new FakeDiscountService(),
    new FakeOrderRepository(),
    new FakePaymentGateway(),
    new FakeInventoryService(),
    new FakeInvoiceService(),
    new FakeEventDispatcher()
);

Test, gerçek harici sistemlere bağlı kalmadan ödeme iş akışını doğrulayabilir.

Service Layer Modeli'nin Faydaları

Service Layer Modeli, nesne yönelimli yazılım tasarımında birçok fayda sağlar.

Ana faydalar şunları içerir:

• Denetleyicileri ince ve odaklı tutar.

• İş mantığını özel sınıflarda düzenler.

• Denetleyiciler, komutlar ve işler arasında yinelemeleri azaltır.

• İş iş akışlarının test edilmesini kolaylaştırır.

• Endişelerin ayrılmasını geliştirir.

• Repositorylar ve bağımlılık enjeksiyonu ile iyi çalışır.

• clean architecture'yu ve kullanım senaryosu organizasyonunu destekler.

• Karmaşık operasyonların sürdürülmesini kolaylaştırır.

Bu avantajlar, servis katmanını orta ve büyük uygulamalarda çok kullanışlı hale getirir.

Service Layer Deseninin Dezavantajları

Service Layer Modeli aşırı kullanıldığında dezavantajlara da sahip olabilir. Çok küçük uygulamalarda, her basit işlem için bir hizmet oluşturmak, gereksiz dosyalara ve karmaşıklığa neden olabilir.

Diğer bir risk ise onlarca ilgisiz yöntemle UserService veya OrderService gibi büyük jenerik hizmetler oluşturmaktır. Bunlar dikkatli bir şekilde yönetilmezse Tanrı sınıfları haline gelebilir.

Hizmet sınıfları odaklanmaya devam etmelidir. Bir hizmet çok fazla büyüyorsa onu daha küçük hizmetlere veya eylem sınıflarına bölmek daha iyi olabilir.

Service Layer Deseni Ne Zaman Kullanılır?

İş mantığı denetleyiciler veya modeller için fazla karmaşık hale geldiğinde Service Layer Desenini kullanın.

Service Layer Modeli şu durumlarda kullanışlıdır:

• Bir denetleyici yöntemi çok uzun oluyor.

• Birden fazla yerde aynı business logicna ihtiyaç vardır.

• Bir iş akışı birden fazla model veya depo içerir.

• İşlem harici APIs veya adaptörleri kullanıyor.

• Mantığın bağımsız olarak test edilmesi gerekir.

• Proje clean architecture veya etki alanı odaklı tasarımı kullanıyor.

• Birden fazla operasyonda işlemlere ihtiyaç vardır.

Bu koşullar mevcutsa, bir hizmet katmanı tasarımı daha temiz hale getirebilir.

Service Layer Deseni Ne Zaman Kullanılmamalı?

İşlem son derece basit olduğunda ve gerçek business logicnı içermediğinde Service Layer Desenini kullanmayın.

Aşağıdaki durumlarda gereksiz hizmetlerden kaçının:

• Denetleyici yalnızca basit bir görünüm döndürür.

• İşlem, ekstra bir mantığı olmayan temel bir CRUD çağrısıdır.

• Hizmet, değer katmadan yalnızca bir model yöntemini sarar.

• Proje küçük ve sadelik daha önemli.

• Hizmet katmanı açıklıktan çok kafa karışıklığı yaratır.

İyi mimari projenin karmaşıklığına uygun olmalıdır.

Service Layer Deseniyle İlgili Yaygın Hatalar

Yaygın bir hata, çok fazla ilgisiz yöntem içeren UserService gibi tüm etki alanı için büyük bir hizmet sınıfı oluşturmaktır. Bu, hizmetin sürdürülmesini zorlaştırır.

Diğer bir hata, depolar zaten kullanıldığında database sorgu ayrıntılarını doğrudan hizmetlerin içine koymaktır. Bu sorumlulukları bulanıklaştırabilir.

Üçüncü bir hata ise ham istek nesnelerinin derinlemesine hizmetlere aktarılmasıdır. Hizmetler, HTTP istek ayrıntılarına bağlı olmak yerine genellikle temiz veriler, DTOs veya etki alanı nesneleri almalıdır.

Dördüncü hata ise esneklik veya test etme söz konusu olduğunda hizmetleri arayüzler yerine doğrudan somut uygulamalara bağlı hale getirmektir.

Service Layer Modeli için En İyi Uygulamalar

Service Layer Modelini etkili bir şekilde kullanmak için geliştiricilerin hizmetleri odaklı ve net tutması gerekir.

Yararlı en iyi uygulamalar şunları içerir:

• Denetleyicileri ince tutun ve iş iş akışlarını hizmetlere devredin.

• Kullanım senaryolarına göre hizmetlere anlamlı adlar verin.

• Repositorylar ve harici hizmetler için bağımlılık eklemeyi kullanın.

• Hizmetlerin sunuma değil business logicna odaklanmasını sağlayın.

• Çok büyük genel hizmet sınıfları oluşturmaktan kaçının.

• İş akışları tutarlılık gerektirdiğinde hizmetlerdeki işlemleri kullanın.

• Uygun olduğunda ham istek nesneleri yerine DTOs veya doğrulanmış dizileri kullanın.

• Repository Pattern kullanırken sorgu mantığını depolarda tutun.

• Önemli hizmet iş akışları için testler yazın.

Bu uygulamalar hizmet katmanının temiz ve bakımı kolay tutulmasına yardımcı olur.

Hizmet Oluşturmadan Önce Pratik Kontrol Listesi

Bir hizmet sınıfı oluşturmadan önce geliştiriciler şu soruları sorabilir:

• Denetleyiciye ait olmayan business logic var mı?

• Bu işlem birden fazla adım içeriyor mu?

• Birden fazla yerden mantık mı gerekiyor?

• İş akışı birkaç bağımlılık kullanıyor mu?

• Operasyonun bir işleme ihtiyacı var mı?

• Bir hizmet testi kolaylaştıracak mı?

• Hizmetin açık ve odaklanmış bir sorumluluğu olabilir mi?

Bu soruların birçoğuna cevabınız evet ise, bir hizmet katmanı muhtemelen faydalı olacaktır.

Service Layer Yeni Başlayanlar İçin Neden Önemlidir?

Yeni başlayanlar için Service Layer Modeli önemlidir çünkü gerçek uygulamalarda business logicnın nereye gitmesi gerektiğini öğretir. MVC örnekleri genellikle basit olduğundan, yeni başlayanların çoğu denetleyicilerin veya modellerin içine çok fazla kod yerleştirir.

Projeler büyüdükçe bu yaklaşımın sürdürülmesi zorlaşır. Hizmet katmanını öğrenmek, yeni başlayanların daha profesyonel Laravel, Symfony ve PHP uygulamaları yazmasına yardımcı olur.

Ayrıca geliştiricileri clean architecture, etki alanı odaklı tasarım, uygulama hizmetleri, kullanım senaryoları ve test edilebilir yazılım tasarımını anlamaya hazırlar.

Sonuç

Service Layer Modeli, business logicnı ve uygulama iş akışlarını özel hizmet sınıfları halinde düzenleyen bir yazılım tasarım modelidir. Denetleyicilerin ince, model odaklı ve iş operasyonlarının yeniden kullanılabilir ve test edilebilir olmasına yardımcı olur.

Service Layer Deseni, MVC, Repository Pattern, Dependency Injection, DTOs, etkinlikler, işler ve clean architecture ile iyi çalışır. İş mantığının denetleyiciler veya modeller arasında dağılmaması gereken orta ve büyük uygulamalarda özellikle kullanışlıdır.

Ancak hizmetlerin dikkatli kullanılması gerekir. Basit CRUD işlemleri bir hizmete ihtiyaç duymayabilir ve büyük genel hizmetlerden kaçınılmalıdır. Doğru uygulandığında Service Layer Modeli temiz, ölçeklenebilir ve bakımı kolay nesne yönelimli yazılım oluşturmak için güçlü bir araçtır.