capodecina Bu sorulara tatmin edici cevaplar alamazsınız çünkü:

1. Bunların bırakın hepsini bir kısmının cevabı için bile kitap yazılır.
2. Modüler yapı imkanlılığı ve uygulama şekli açısından projeden projeye göre değişen bir şey.

Laravel adına konuşmak gerekirse bakmanız gereken yer şurası:
https://laravel.com/docs/8.x/packages

Moduler bir yapıya gerçekten ihtiyacınız var mı önce onu netleştirmeniz lazım. Benim genellikle rastladığım hata bir projenin olmazsa olmazlarının bile modulleştirilmeye çalışılması. Yani e-ticaret yazıp da sepeti modül olarak sisteme dahil etmenin bir anlamı yok çünkü business açısından o bir gereksinim. Sadece çok büyük projelerde birden fazla takım çalıştığında her takımın bağımsız geliştirme yapabilmesi adına moduler yapı mantıklı olabilir.

Ben yine cevaplamaya çalışayım, bunlar benim şahsi düşüncelerimdir:

Listener,Subscriber gibi bir yapıyla modulerlik ne derecede sağlanabilir?
Moduler yapı gibi yapılar biraz ütopiktir. Hiçbir zaman istediğiniz derecede istediğinizi elde edemeyeceksiniz.

Bazı moduller içerik olarak diğer modullere daha geniş bir kapsama sahip olacaktır. Bu durumunda modulerliğin yapısına zarar vermez mi? Bunu daraltmalımıyız? Ne kadar daraltabiliriz? Daraltma neye göre yapılmalı? Nelere dikkat edilmeli?
Modulleri belirleyen boyutları değil işlevleri. Bunu düşünüyorsanız önce de dediğim gibi moduler bir yapıya gerçekten ihtiyacınız var mı önce onu netleştirmeniz lazım.

Listener,Subscriber dışında uygulanabilecek çözümler nelerdir?
Her bir modülün kendine ait bir kernel ile sisteme bağlanması. Laravel'de bunu service provider'lar aracılığıyla yapıyoruz. Araya mutlaka bir bridge lazım.

Mutlak bir şekilde hiç bir modul birbirinin var olup olmadığını bilmeli mi? Bilmeliyse ne derecede?
Bazı modüller başka modüllere ihtiyaç duyabilir; başka modullerin kaldırılmasını isteyebilir. %100 bilmesi de gerekebilir %0 da.

Modulerliği sağlamak için composer ile paket yönetimi mi yapılmalı? Uygulama içerisinde modules adında bir dizin altında tutularak da bu gerçekleştirilebilir mi bunun bir dez avantajı var mıdır?
Paket kullanmak daha mantıklı çünkü paket sayesinde kullanılmayan bir modül sistemde yer almaz ve yönetimi kolay olur. Ayrıca modules isimli bir klasörün altında kodları bölmek bana göre moduler bir yapı değil sadece bir çeşit dosya/klasör organizasyonu. Domain (DDD) olayı var ama o farklı bir şey.

Moduler bir uygulama ile başlayıp sonu monolithic bir uygulama da son bulma ihtimali nedir?
Yüksektir. Modullerin bağlandığı ana iskelet eğer herhangi bir modül olmadan kendi başına uygulamanın business ayağını gerçekleştirebiliyorsa, sadece ek işlemler için modüllere ihtiyaç duyuyorsa aslında monolitiktir. Moduler yapı yerine şu anda revaçta olan mikroservis mimarisine yönelmeniz bence daha mantıklı. Modüler bir uygulama gerçekten çok iyi bir planlama ve ekip isteyen bir iş.

Bir uygulama ortaya çıkarmanın birden fazla yolu var ve bence modüler yapı kesinlikle bu işin basit ve efektif yolu değil. Java'da oluğu gibi soyutların, desenlerin arasında kaybolursunuz...

Moduler yapı gibi yapılar biraz ütopiktir. Hiçbir zaman istediğiniz derecede istediğinizi elde edemeyeceksiniz.

Muhteşem bir cevap @mgsmus hocam. Hayatımın özeti adeta.

Ayrıca modules isimli bir klasörün altında kodları bölmek bana göre moduler bir yapı değil sadece bir çeşit dosya/klasör organizasyonu.

Bu da çok güzelmiş.

Kendi cevabıma gelecek olursak;

• Modülerliğin sınırları belli değildir aslında. Bu projeye göre değişir. Yani ne olursa modüler diyeceğiz, kısımlar birbirinden ne kadar ayrıştıktan sonra modüler diyeceğiz? Bir iş mülakatında sordular; mikroservisler aynı veritabanını kullanabilir mi diye, evet dedim kullanabilir. Sen bu işi bildiğine emin misin dediler. Onların sınırları çok keskindi, evet mikroservis mantığında her servis kendi veritabanını kullanır ama gerekirse aynı veritabanını da kullanabilir bu kadar kesin çizgi yazılımda yoktur. Yazılım geliştirirken uymamız gereken iyi kullanımlar (best practise) var ama kanunlarımız yok. Bu yüzden sınırlarımız da yok. En son FaaS modeline geçebilirsiniz sonuna kadar modüler yapacağım derseniz. Her metodunuz ya da API ucunuz ayrı bir proje gibi deploy edilir. Bu yüzden sınırları belli olmayan bir konu için kesin cevaplar vermek de pek mümkün değildir.
• Bir projeyi modüler yapmanın birden fazla yolu vardır. Bu yüzden örneğin

Listener,Subscriber gibi bir yapıyla modulerlik ne derecede sağlanabilir?

Sorusuna çok veya az diyemeyiz. Çünkü örneğin ekibiniz Listener/Subscriber mantığına aşina değilse framework kullanarak spagetti yazan kişilerin yazdığı proje gibi olur projeniz. Ek olarak sadece Listener/Subscriber mantığını da bir çok farklı yolla kullanabiliriz. Mesela PostgreSQL'in de listener subscriber özelliği var. Bu işi veritabanı katmanında mı yapacağız, RabbitMQ ile mi yapacağız, Laravel ile mi yapacağız? Hepsi projem ne kadar modüler sorusunun cevabını değiştirir.

Benim sınırım şu, bir modül projeden bağımsızsa kendi başına çalışabiliyor istediğim projede kullanabiliyorsam o benim için bir modüldür (mikroservisten bahsediyorum doğru). Ama bir başkası için tamamen yanlış bir yaklaşım olabilir bu düşünce.

Asıl soru şu olabilir; böyle bir projem var, ekibim bu kadar, ekibimin yetkinlikleri bu kadar, bütçem bu kadar, bitirme sürem bu kadar, kullanacağım teknolojiler bunlar... ben nasıl bir modüler yapı kurabilirim. Böyle bir soruya daha net ama tam net olmayan bir cevap verilebilir.

Destansı hikayeler yazılır burada bu sorulara. Benden şimdilik bu kadar.
Kolay gelsin.