coder2 İletişim sosyolojisinde şöyle bir şey vardır: Almanları ayağa kaldıran Hitler değil radyodur; radyo mesajın kendisidir. Almanlar aslında Hitleri değil radyoyu onaylıyordu. Bunu söylememin sebebi, yeni başlayanlar ya da fazla bilgi sahibi olmayanlar genellikle Laravel ile bir uygulama yazdıklarında Laravel'in mevcut yapısını bozmadan, sadece eklemeler yaparak birebir dinamiklerini kullanarak geliştirme yapar. Bu da aslında başlangıç için önerilen yoldur. Yani controllerlar app/Http/Controllers içine, modeller app/Models içine vs... Sonra bana getirip ben Laravel ile şu uygulamayı yaptım dediklerinde ben orada uygulama görmüyorum, Laravel görüyorum (yani radyo). Laravel'in elini yüzünü değiştirip uygulamaya benzetmiş aslında, bunun adı da uygulama geliştirme oluyor. Ben ise öyle düşünmüyorum. Ben Laravel'i uygulama olarak değil araç olarak kullanıyorum. Laravel üzerine önce uygulamama yardımcı olacak ayrı bir framework inşa ediyorum, buna ben Application diyorum. Bu framework Laravel'in özelliklerini kullanıyor, ondan destek alıyor ama mümkün olduğunca da onun yapısından izole. Bu framework kendi içinde katmanlara ayrılıyor ve bu katmanların en üstünde ise servis katmanı var. Bu servis katmanı ise benim uygulamamın business tarafını oluşturuyor.
Bu şekilde hareket ettiğimde benden bir geliştirme istendiğinde ben Laravel'e kadar inmiyorum, benim artık Laravel ile işim yok, benden istenen geliştirme business ile alakalı, benim Application katmanım bunu çözüyor. Hatta bazen mevcut servisleri kullanarak bile hallediyorum. Başka bir geliştirici devreye girdi mi benim yazdığım servisi kullanıyor. Servis ihtyacını karşılamıyorsa servisin içine kendi yöntemini ekliyor vs
Servisleri kullanırken public function build(User $user)
yerine public function build(int $userId)
şeklinde bağımlılıkları da mümkün olduğunca az tutmaya çalışıyorum. Böylece bazı gereksinimlerin elde edilemediği ortamlarda bağımsız çalışmalarını sağlıyorum. En çok hatayı burada yapıyorlar. Bağımlılık olarak Request kullanıp console içinde bunu kullanmaya çalışıyorlar, command içinde ValidationException fırlatıyorlar, observer içinde Auth geziyor vs...
Kısacası DDD'de ne bir standart ne de en iyi yol diye bir şey var, sadece benzer ya da denk açıklamalar ile karşılaşırsınız çünkü her faktöre göre değişen bir yapı inşasından bahsediyoruz. Bana göre kendinizi nasıl rahat hissediyorsanız öyle hareket edin. Ben kendi yapımda bir çok prensibi bilerek çiğniyorum çünkü teorik her kurgu pratikte mümkün değil ve basitlik ilkesi benim için önemli.