Kurumsal sis­tem­ler için Laravel

Web framework'leri kadar inanç beyanına konu olan pek az araç vardır. Bir kesim Laravel'i ciddi sistemler için fazla oyuncakçı bulur, diğeri ise her gereksinimin cevabı sayar. İki taraf da aynı işe yaramaz soruyu sorar — framework'ün “yeterince iyi” mi yoksa “daha iyi” mi olduğunu — ve ikisi de buna kullanılabilir bir yanıt alamaz, çünkü sorunun bir yanıtı yoktur.

Bu doküman başka bir soru soruyor: Bir sistemin hangi özellikleri var ve bunlar aracın özellikleriyle örtüşüyor mu? Hiçbir yerde Laravel'in bir alternatiften daha iyi olduğunu iddia etmiyor. Nerede taşıdığını, nerede taşımadığını ve iş açısından kritik bir ortamda on yıl boyunca işletmenin neye mal olduğunu anlatıyor. Kendi framework'ü için bir tavsiye arayan hayal kırıklığına uğrayacak; gerekçeli bir karar için temel arayan ise onu burada bulacak.

1. Kurumsal gerçekte ne anlama gelir

“Kurumsal” (enterprise) bir büyüklük ölçüsü değildir. Kullanıcı sayısını, şirketin cirosunu ya da müşteri listesinin uzunluğunu tarif etmez. Bir sistemi — onu kaç kişinin kullandığından bağımsız olarak — zorlaştıran bir dizi özelliği tarif eder.

Kurumsal sistemler uzun yıllar kullanılır ve bu süre içinde geliştirme ekipleri değişebilir. Farklı beklentilere sahip çok sayıda paydaşla ve işletmenin kontrolü dışındaki sistemlerle birlikte çalışırlar. Erişim kontrolü, izlenebilirlik ve denetlenebilirlik temel gereksinimlerdir. Bu nedenle geliştirme hızının yanı sıra gelecekteki değişikliklerin maliyeti ve güvenle yapılabilmesi önem taşır.

Framework sorusunun ölçütü bu tanımdan çıkar. Bir framework, ilk sürümü olabildiğince hızlı teslim ettiğinde değil, bir sistemi uzun bir süre boyunca, değişen ekiplerle ve entegrasyon baskısı altında değiştirilebilir tutmaya yardım ettiğinde kurumsal kullanıma uygundur. Başlangıçtaki hız ucuza elde edilir; sondaki değiştirilebilirlik asıl ödenen bedeldir.

Avantajlar ve sınırlamalar. Kurumsal uygunluğu yalnızca büyüklükle tanımlamamak, her sistemin gereksinimlerini ayrı değerlendirmeyi gerektirir. Tek bir evet veya hayır yanıtı yeterli değildir.

Maliyet. Bu bakış açısı, bir kararın uzun vadeli maliyetlerini görünür hâle gelmeden önce tahmin etmeyi gerektirir — proje baskısı altında kolayca bir sonraki kilometre taşına kurban edilen bir disiplin.

Ne zaman farklı karar veririz. Bir sistem bu özelliklerin hiçbirini taşımıyorsa — kısa ömürlü bir araç, bir prototip, izole bir dahili yardımcı —, kurumsallık sorusu anlamsızdır ve karar yalnızca teslim hızına göre verilmelidir.

2. Laravel nerede uygundur

Laravel'in gücü, zengin iş mantığı, çok sayıda ekran ve iş akışıyla şekillenen sistemlerde yatar — değerin ham işlem gücünden değil, süreçlerin modellenmesinden doğduğu uygulamalarda. İşletme yazılımlarının büyük çoğunluğu için tarif tam olarak budur: siparişler, sözleşmeler, başvurular, onaylar, faturalandırmalar, durumların zaman içinde yönetimi.

Bunun nedeni ekosistem ve sürekli tekrarlanan yapı taşlarının olgunluğudur. Kimlik doğrulama, yetkilendirme, kuyruklar, zamanlanmış görevler, veritabanı migrasyonları, doğrulama, olaylar, test araçları — hepsi mevcut, birbiriyle uyumlu ve geniş ölçüde denenmiştir. Bir ekip bu temelleri kendisi inşa etmek zorunda kalmaz ve zamanını sistemi benzersiz kılan şeye yöneltebilir: iş alanına. Çok sayıda standart bileşene ve daha küçük bir gerçek özgünlük çekirdeğine sahip uygulamalar için bu yapı çok elverişlidir.

Buna geliştiricilerin bulunabilirliği de eklenir. Pek çok kişinin bildiği bir framework, bir ekibi yıllar boyunca kadrolu tutmanın maliyetini düşürür — kelimenin tam anlamıyla bir kurumsal özellik, çünkü sistemin onu inşa edenlerin değişiminden sağ çıkması gerekir.

Avantajlar ve sınırlamalar. Hazır framework bileşenleri geliştirmeyi hızlandırır. Ancak iş kuralları bu bileşenlere sıkı bağlanırsa sonraki değişikliklerin maliyeti artar (bkz. Bölüm 4).

Maliyet. Ekosistemin olgunluğu sizi onun konvansiyonlarına bağlar. Yalnızca yapı taşlarını değil, onların varsayımlarını da miras alırsınız; bunlara karşı çalışan, avantajın bir kısmını kaybeder.

Ne zaman farklı karar veririz. Bir sistem neredeyse yalnızca olağan standart bileşenleri olmayan küçük, çok özel bir çekirdekten oluşuyorsa ekosistem avantajı erir ve seçim yalnızca bu çekirdeğin özelliklerine göre yapılmalıdır.

3. Laravel nerede uygun değildir

Dürüst bir karar dokümanı sınırları güçlü yanlardan daha net adlandırır. Laravel — ve altında yatan çalışma modeli — gereksinimin iş alanından değil, ham makine özelliklerinden oluştuğu yerde pek uygun değildir.

Bu öncelikle sıcak yoldaki (hot path) hesaplama yoğun görevleri kapsar: kapsamlı sayısal işlemler, sinyal veya görüntü işleme, bir dilin saf çalışma hızına dayanan her şey. Her milisaniyenin önemli olduğu ve yorumlanan, her istekte yeniden kurulan bir modelin engel oluşturduğu katı gerçek zamanlı ve çok düşük, garanti edilmiş gecikme gereksinimlerini kapsar. Tekil bağlantılar üzerinde son derece yüksek, sürekli eşzamanlılığı kapsar — örneğin çok sayıda kalıcı açık bağlantı —; bunlar için başka çalışma modelleri tasarlanmıştır. Ve derleyici tarafından baştan sona zorunlu kılınan katı bir tip güvenliğinin sabit bir gereksinim olduğu ortamları kapsar; dilin dinamik kökleri çok fazla disipline izin verir ama onu zorunlu kılmaz.

Bu durumlarda doğru yanıt Laravel'i “daha iyi hâle getirmek” değil, ilgili kısmı daha uygun bir araçla inşa edip net bir arayüz üzerinden bağlamaktır. Kurumsal bir sistem zaten nadiren tek bir araçla inşa edilir.

Avantajlar ve sınırlamalar. Bir işlevi ayrı sisteme taşımak, uygun teknolojiyi kullanma olanağı verir. Karşılığında işletilmesi, izlenmesi ve sürümlenmesi gereken yeni bir sınır oluşur.

Maliyet. Her dil ve çalışma zamanı sınırı işletimin bir kısmını ikiye katlar: iki deployment, iki gözlem zinciri, ekipte iki yetkinlik profili.

Ne zaman farklı karar veririz. Hesaplama yoğun veya gecikmeye duyarlı kısım küçük ve seyrekse, ikinci bir teknoloji getirmek yerine onu mevcut yapı içinde önbellekleme veya asenkron işleme ile hafifletmek daha uygun olabilir. Ek sınır, ancak bu kısım sistemin karakterini belirlediğinde bedelini karşılar.

4. Mimari ilkeler

Kurumsal bağlamda Laravel hakkındaki en önemli cümle şudur: Framework kabuktur, çekirdek değil. Laravel, iş alanını doğrudan kendi yapı taşlarına yazmaya izin verir — hatta neredeyse davet eder: controller'da iş kuralları, Eloquent modelinde davranış, framework olaylarında süreçler. Küçük bir uygulama için bu hızlı ve yerindedir. Uzun ömürlü bir sistem için ise sonraki acıların çoğunun nedenidir, çünkü iş alanını framework'ün sürümüne zincirler.

Bu yüzden yol gösteren ilke, iş mantığını framework'ten bağımsız tutmaktır — HTTP'den, Eloquent'ten ve Laravel'in yaşam döngüsünden hiçbir şey bilmeyen bir domain katmanında. İşin kuralları basit sınıflarda durur; framework onları içermek yerine çağırır. Eloquent bu durumda olduğu şey olarak ele alınır — kalıcılığa erişim yolu olarak —, iş alanının yeri olarak değil. Bu ilke başka bir yerde ayrıntılı olarak ele alınmıştır: İş mantığı controller'a ait değildir.

Yapısal olarak bu, kurumsal sistemlerin çoğu için şu anlama gelir: Bağımlılıkların içe doğru — framework kabuğundan iş çekirdeğine, asla tersine değil — yöneldiği, net iç sınırlara sahip bir modüler monolit. Böylece çekirdek framework'ün modalarından etkilenmez ve bir yükseltme işi değil, kabuğu etkiler.

Şema: Framework iş alanını sarar ve onu çağırır. Bağımlılıklar içe doğru yönelir — çekirdek framework'ü tanımaz.

Avantajlar ve sınırlamalar. Ayrı bir domain katmanı, iş mantığını framework’ten ayırır. Başlangıçta daha fazla yapı ve emek gerektirebilir; doğrudan controller içinde kod yazmaktan daha yavaş olabilir.

Maliyet. Bu disiplin daha deneyimli geliştiriciler ve baştan itibaren daha fazla yapı gerektirir — karşılığını ancak sistemin ömrü boyunca veren, ilk çeyrekte ise yük gibi görünen bir efor.

Ne zaman farklı karar veririz. Kısa ömürlü veya küçük uygulamalar için framework'e yakın yapı doğru olandır: Orada Laravel'e sıkı bağlılık bir risk değil, hızdır ve bir domain katmanı aşırı mühendislik olurdu.

5. Uzun vadeli sürdürülebilirlik

Uzun vadeli bakım açısından iki konu önemlidir: sürüm yükseltmelerinin maliyeti ve iş mantığının örtük framework davranışlarına ne kadar bağlı olduğu. Laravel düzenli ana sürümlerle gelişir. Bu, araçların güncel kalmasını sağlar; ancak sürüm yükseltmelerini uzun süre ertelemek, daha sonra kapatılması zor bir teknik borç oluşturur.

Bu borca karşı en etkili kaldıraç Bölüm 4'teki ayrımdır. İş alanı framework'ten bağımsız bir çekirdekte duruyorsa bir yükseltme yalnızca kabuğu etkiler ve maliyetler yönetilebilir kalır. İş alanı ise controller'lara, modellere ve framework olaylarına dağılmışsa her yükseltme bütün sistem boyunca bir yürüyüşe dönüşür. Yani yükseltme maliyetleri framework'ün bir özelliğinden çok, kendi mimarinizin bir özelliğidir.

Laravel’in örtük davranışları, daha az kodla hızlı geliştirmeyi sağlar; ancak sistemin nasıl çalıştığını anlamayı zorlaştırabilir. Uzun yıllar kullanılan bir uygulamada kod, yazıldığından çok daha sık okunur ve değiştirilir. Bu nedenle kritik iş mantığında açık ve anlaşılır yapıya öncelik veriyor, framework kolaylıklarını altyapı katmanlarında kullanıyoruz.

Avantajlar ve sınırlamalar. Açık davranış ve bağımlılıklar, başlangıçta daha fazla kod gerektirebilir. Karşılığında uygulamayı geliştirmemiş kişiler de sistemi daha kolay anlayabilir.

Maliyet. Disiplinli bir yükseltme temposu, görünür hiçbir şey üretmeyen kapasiteyi kalıcı olarak bağlar — onsuz daha sonra çok daha pahalıya gelecek bir aksamaya karşı ödenmiş bir önlem.

Ne zaman farklı karar veririz. Bir sistemin kısa ömürlü olacağı öngörülebiliyorsa, sihirli ve framework'e yakın yapı ekonomik açıdan doğru olandır; katı bir yükseltme disiplini karşılığı olmayan bir efor olurdu.

6. Ölçeklenmenin gerçekleri

Laravel uygulamaları durumsuz (stateless) tasarlandığında yatay olarak ölçeklenebilir. Yük dengeleyicinin arkasına ek uygulama örnekleri konularak istekler dağıtılır. Ancak tüm örnekler aynı veritabanını kullanıyorsa darboğaz veritabanında oluşabilir. Bu nedenle ölçeklenmeyi yalnızca uygulama sunucusu sayısını artırmak olarak değerlendirmemek gerekir.

Bu, ölçeklenme işini framework'ten uzaklaştırıp veri modeline, indekslemeye, sorgulara ve işin bilinçli olarak dışarı alınmasına kaydırır. Yükün büyük kısmını iki araç taşır: işi istek yolundan çıkarmak için kuyruklar (Queue mu senkron işleme mi ilgili değerlendirmeyi ele alır) ve tekrarlanan okuma yükünü kaynaktan uzak tutmak için önbellekleme — beraberinde getirdiği tüm çekincelerle birlikte. Her ikisi de framework anahtarları değil, mimari kararlardır.

Klasik çalışma modelinde uygulama her istek için yeniden başlatılır. Bu yaklaşım izolasyonu kolaylaştırır, ancak her istekte başlangıç maliyeti oluşur. Uzun süre çalışan süreçlerde uygulama bellekte tutulur ve bu maliyet azalır. Karşılığında, istekler arasında kalan durumun kontrollü biçimde temizlenmesi gerekir. Seçim performans kazancı ile durum yönetimi sorumluluğu birlikte değerlendirilerek yapılmalıdır.

Şema: Durumsuz uygulama katmanı çoğaltılarak ölçeklenir. Arkasındaki paylaşılan depolama ölçeklenmez — asıl ölçeklenme işi oradadır.

Avantajlar ve sınırlamalar. Yatay ölçeklenme, uygulama sunucularında ve veritabanında farklı maliyetler doğurur. İş yükünü ayırmak bir katmanı rahatlatırken sistemin genel karmaşıklığını artırabilir.

Maliyet. Her ölçeklenme önlemi — kuyruk, önbellek, uzun süre çalışan süreç — izlenmesi ve hata durumunda anlaşılması gereken bir işletim parçası ekler.

Ne zaman farklı karar veririz. Tek bir örnek ve iyi indekslenmiş bir veritabanı yükü taşıdığı sürece bu önlemlerin hiçbirini devreye almayız — bunlar, sahip olmadan önce ölçülmüş olması gereken bir sorunu çözer.

7. İşletim

Kurumsal bir sistem geliştirildiğinden daha uzun süre işletilir ve itibarı da maliyetleri de işletim belirler. Laravel'in işletim yüzeyi salt bir uygulamanınkinden daha geniştir: Uygulama örneklerinin yanında kuyruk worker'ları, zamanlanmış görevler ve çoğu zaman bir önbellek ve bir kuyruk servisi çalışır. Bu parçaların her biri kendi hata modlarına sahip ayrı bir işletim nesnesidir.

İki alan özel bir özeni hak eder. Birincisi, yeni sürümlerin kesinti olmadan devreye alınmasıdır, özellikle veritabanı değişiklikleriyle birlikte — Kesintisiz veritabanı migrasyonları yazısında ele alınan ve tesadüfe bırakılmaması gereken ayrı bir disiplin. İkincisi kuyruk worker'larıdır: Bunlar “ateşle ve unut” değildir; başarısız işler, tekrar denemeler ve bir worker'ın işlemenin ortasında ölmesi durumu için bir plana ihtiyaç duyarlar — dağıtık sistemlerin genel olarak gerektirdiği aynı tekrarlanabilirlik disiplini.

Her şeyin üzerinde gözlemlenebilirlik durur. Kuyruklarını, zamanlanmış görevlerini ve önbelleklerini ölçemediğiniz bir sistem, hata durumunda bir kara kutudur. Bu yüzden gözlemlenebilirlik sonradan eklenen bir malzeme değil, mimarinin bir parçasıdır — Bir mimari ilke olarak observability yazısında ele alındığı gibi.

Avantajlar ve sınırlamalar. Kuyruk, zamanlayıcı ve önbellek gibi araçlar yeni olanaklar sağlar. Karşılığında izlenmesi ve bakımı yapılması gereken bileşen sayısı artar.

Maliyet. Her işletim parçası izleme, alarm ve prova edilmiş müdahaleler gerektirir; kurumsal bir Laravel'i işletmek, bir uygulamayı devreye almaktan fazlasıdır.

Ne zaman farklı karar veririz. Bir uygulama arka plan işi olmadan idare edebiliyorsa, yüzeyi “ileride lazım olur” diye kurmak yerine kuyruktan ve zamanlayıcıdan bilinçli olarak vazgeçeriz — kullanılmayan işletim parçaları karşılığı olmayan risktir.

8. Ekip organizasyonu

Laravel'in düşük giriş eşiği aynı zamanda en büyük organizasyonel riskidir. Ekipleri hızla üretken kılar ve pozisyonları doldurmayı kolaylaştırır — ikisi de gerçek kurumsal avantajlardır. Ancak aynı erişilebilirlik her kestirme yolu kullanmaya da izin verir: iş mantığını controller'a, modelde bir erişim daha, küçük bir sorun için bir paket daha. Framework'ün izin verdiği şeyi, baskı altındaki bir ekip, hiçbir şey onu durdurmuyorsa yapacaktır.

Denge framework'te değil, organizasyonda yatar: framework'ünkilerin ötesine geçen ve iş alanını framework'ten ayıran bağlayıcı konvansiyonlar; herkesin her yere yazması yerine bir ekibin bir alanın sahibi olacağı şekilde ekipler arasındaki sınırlarla örtüşen kod sınırları; ve stile değil, iş alanının ait olduğu yere yerleşmesine dikkat eden bir review. Framework'ün konvansiyonları onboarding için bir armağandır — ama uzun ömürlü bir sistemi bir arada tutan mimari konvansiyonların yerini tutmazlar.

Avantajlar ve sınırlamalar. Ekip içi geliştirme kuralları, büyük ve değişen ekiplerde tutarlılığı destekler. Karşılığında bireysel tercihleri sınırlar ve başlangıçta uyum sağlama emeği gerektirir.

Maliyet. Konvansiyonların yazılması, öğretilmesi ve review'da uygulatılması gerekir — hiçbir özellik üretmeyen, disipline yapılan kalıcı bir yatırım.

Ne zaman farklı karar veririz. Küçük bir uygulama üzerinde çalışan küçük bir ekipte ağır konvansiyonlar bürokrasi olurdu; orada framework konvansiyonları yeterlidir ve ek yapı korumaktan çok frenlerdi.

9. Tipik hatalar

Kurumsal Laravel'in başarısız olduğu tekrarlayan örüntüler — neredeyse hepsi aynı hatanın, framework'ü kabuk yerine çekirdek yapmanın varyasyonlarıdır:

• İş mantığını controller'lara ve Eloquent modellerine koymak; böylece iş alanı framework sürümüne zincirlenir ve her yükseltme bütün sisteme dokunur.
• İş çekirdeğinde örtük “sihre” güvenmek ve böylece yazma hızını yıllarca sürecek okuma maliyetleriyle takas etmek.
• Yükseltmeleri, birkaç sürümlük atlama sakin bir an için fazla büyük ve fazla riskli hâle gelene kadar ertelemek.
• Darboğaz paylaşılan veritabanı olduğu hâlde ölçeklenmeyi framework'te aramak — indeksler ve sorgular kontrol edilmeden kalır.
• Kuyrukları başarısız, mükerrer veya yarıda kesilmiş işler için bir plan olmadan “ateşle ve unut” olarak ele almak.
• Her küçük sorun için bir paket daha eklemek ve böylece her yükseltmede birlikte taşınması gereken bir bağımlılık yükü oluşturmak.
• Düşük giriş eşiğini mimari olgunlukla karıştırmak ve herkes her yere yazana kadar sınırsız inşa etmek.
• Hesaplama yoğun veya gecikmeye duyarlı bir kısmı, daha uygun bir araçta bir sınırın arkasında inşa etmek yerine framework içinde zorlamak.
• Kuyruklar, zamanlayıcı ve önbellek için gözlemlenebilirliği, işletimde açıklanamayan bir şey olduktan sonra eklemek.

10. Karar kontrol listesi

Kurumsal bir sistem için Laravel'i seçmeden önce sırasıyla netleştirilmesi gerekenler:

• Sistemin karakteri? Değer iş alanından, süreçlerden ve çok sayıda ekrandan mı doğuyor — yoksa ham işlem gücünden ve garanti edilmiş düşük gecikmeden mi?
• Sıcak yol hesaplama yoğun mu? Saf çalışma hızına dayanan bir kısım var mı — ve varsa bu kısım bir sınırın arkasında başka bir araca mı ait?
• Domain katmanı planlandı mı? İş alanını controller'lara ve modellere yazmak yerine framework'ten bağımsız tutmaya karar verildi mi?
• Yapı? Bağımlılıkları içe doğru yönelen modüler bir monolit mi öngörülüyor, yoksa sistem düzensiz mi büyüyor?
• Yükseltme disiplini? Borç birikmeden önce düzenli sürüm bakımı için kapasite planlandı mı?
• Ölçeklenme doğru yerde mi? Darboğazın veritabanı olduğu ve ölçeklenme işinin orada ve bilinçli dışarı almada yattığı net mi?
• İşletim düşünüldü mü? Kesintisiz devreye alma, kuyruk hata durumları ve gözlemlenebilirlik en baştan öngörüldü mü?
• Ekip ve konvansiyonlar? Framework'ün kestirmelere izin verdiği yerde iş alanını koruyan şirket içi konvansiyonlar ve kod sınırları var mı?
• Dürüst bir alternatif incelendi mi? Seçim, somut bir alternatife karşı tercihe göre değil, sistem özelliklerine göre gerekçelendirildi mi?

Bu sorulara yanıt veremeyen, kurumsal bir framework değil, bir başlangıç hissi seçer — ve aradaki farkı sistemin ömrü boyunca öder.

Sıkça Sorulan Sorular

Laravel “enterprise-ready” mi? Sorunun anlamlı bir yanıtı yoktur, çünkü “kurumsal” bir framework'ün değil, bir sistemin özelliğidir. Laravel, iş alanı framework'ten ayrıldığı ve bir yükseltme disiplini sürdürüldüğü sürece uzun ömürlü, iş açısından kritik sistemleri iyi taşır. Bu mimari olmadan hiçbir framework yıllar boyunca taşımaz — “daha ciddi” görünen bir framework de.

Laravel daha katı bir alternatiften daha hızlı veya daha iyi mi? Genel olarak hayır ve soru yanıltıcıdır. Belirli bir sistem türü için — çok sayıda standart bileşene sahip, iş alanı zengin uygulamalar — çok uygundur, diğerleri için — hesaplama veya gecikme odaklı çekirdekler — daha az. Seçim, framework'lerin sıralamasına göre değil, sistemin özelliklerine göre yapılır.

Laravel büyük yük için ölçeklenir mi? Durumsuz uygulama katmanı yatay olarak iyi ölçeklenir; darboğaz neredeyse her zaman paylaşılan veritabanıdır. Bu yüzden “Laravel ölçeklenir mi” nadiren doğru sorudur — doğru soru, veri modelinin, indekslemenin ve işin dışarı alınmasının beklenen yükü taşıyıp taşımadığıdır.

Her şeyi Laravel ile mi inşa etmeliyiz, yoksa bazı kısımları dışarı mı almalıyız? Hesaplama yoğun veya gecikmeye duyarlı bir kısım sistemin karakterini belirliyorsa, onu net bir arayüzün arkasında daha uygun bir araçla inşa edersiniz. Kısım küçük ve seyrekse, ikinci bir teknoloji işletmek yerine onu mevcut yapı içinde önbellekleme veya asenkron işleme ile hafifletmek çoğu zaman daha uygundur.

Yükseltme maliyetlerini nasıl düşük tutarız? İş alanını framework'ten bağımsız bir çekirdekte tutarak. O zaman bir yükseltme yalnızca kabuğu etkiler. Yükseltme maliyetleri Laravel'in bir özelliğinden çok, kendi mimarinizin — ve sürümleri ne kadar düzenli takip ettiğinizin — bir özelliğidir.

Düşük giriş eşiği kurumsal ortamda bir avantaj değil mi? İkisi birden. Onboarding ve kadro maliyetlerini düşürür ve aynı zamanda her kestirme yola izin verir. Avantaj ancak hızlı üretkenliğin dağınık bir sisteme dönüşmesini önleyen şirket içi konvansiyonlar ve kod sınırlarıyla korunur.

İleri okuma

• Laravel mi Symfony mi — iki PHP framework'ünün kazananı olmayan, dürüst mimari karşılaştırması.
• İş mantığı controller'a ait değildir — iş alanını framework'ten ayırmanın temel ilkesi.
• Modüler monolit ve mikroservisler ve ilgili karar — kurumsal sistemlerin çoğu için uygun temel yapı.
• On yıl sonra da çalışan yazılım — değiştirilebilirliğin neden ömür boyunca asıl ölçüt olduğu.

Temeli Batunet Engineering Method'tur: sistemin özelliklerine göre karar vermek, iş alanını araçtan ayırmak, sistemin ömrü için inşa etmek.

Bir framework bir araçtır, bir inanç beyanı değil. Soru hiçbir zaman iyi olup olmadığı değil, inşa ettiğiniz şeye uyup uymadığı — ve onu on yıl taşımanın neye mal olacağıdır.