Yazılımın mimarisinde genellikle sorunlara yol açan geleneksel ilkeler vardır. Bu zorlukları sevmek, onları ortadan kaldırmak ve hatta baştan kaçınmak için ilk adımdır.
Yıllardır birçok projeyi de uygulayan mimari ilkelerde dövüldük. Bu nedenle, şimdi bu ilkelerin gerçekten yararlı olduğu hakkında bilgi var. İlk bakışta, fikirler yararlıdır ve kanıtlamasalar bile alışkınsınız. Başarısızlıklar hakkında konuşmaktan hoşlanmayın.
Bazı örnekler:
TL; Dr.
Bu yüzden yazılım mimarisi gelişir, neyin işe yaramadığına veda etmeliyiz. Ama o kadar kolay değil, çünkü ilkeler artık kırılması gereken bir gelenek.
()
Yıllardır birçok projeyi de uygulayan mimari ilkelerde dövüldük. Bu nedenle, şimdi bu ilkelerin gerçekten yararlı olduğu hakkında bilgi var. İlk bakışta, fikirler yararlıdır ve kanıtlamasalar bile alışkınsınız. Başarısızlıklar hakkında konuşmaktan hoşlanmayın.
Bazı örnekler:
- Birçok proje, bileşenlerin yeniden kullanılmasına izin vermeyi amaçlamaktadır. Ama pratik olarak yeniden kullanımdan yararlanan projelerle asla karşılaşmıyorum. Böylece bu hedefe ulaşılamaz. Buna ek olarak, yeniden kullanımın önceki blog yayınları gibi dezavantajları vardır. Ancak yeniden kullanım çok tipik bir hedef olduğu için veda etmek zor.
- İdeal olarak, veriler fazlalıktan ücretsiz olarak kaydedilmelidir. Ayrıca, nesne oryantasyonu bize nesne yönelimli modelleri öğretti. Dolayısıyla, etki alanı, veritabanında kalıcılık ile fazlalık olmadan nesneye yönelik tek bir modelde modellenir. Bu modeller genellikle son derece karmaşıktır ve veritabanında yüzlerce tablo veya sütun vardır. Çözüm, alan adı tarafından yönlendirilen tasarımla sınırlı bir bağlamdır: bir model yerine, sistem farklı özel modeller kullanır. Bu modeller de genellikle fazlalıksızdır: “Ödeme” bağlamındaki bir sipariş için model, “teslimat” bağlamındakilerden tamamen farklı verilere sahiptir.
- Nihayetinde, mimarlık için bazı hedefler genellikle gereklidir. Bir örnek ölçeklenebilirliktir. Bu aynı zamanda mantıklıdır: İyi mimari ölçeklenebilirlik sunmalıdır. Azaltılmayan bir sistem önemli bir sorun olabilir. Öte yandan, ölçeklenebilirlik aslında lüks bir sorundur, çünkü bu bir sistemin zaten gerçekleştiği ve şimdi genişletilmesi gerektiği anlamına gelir. Bu nedenle, herhangi bir hipotezi karşılamadan önce mimari için gerçek gereksinimleri belirlemelisiniz. Bir sistem, uygunluk veya güvenlik nedeniyle üretime girmezse, ölçeklenebilirlik yararlı değildir. Bunun için zaten bir blog yazısı vardı. Tabii ki, ilk kural yazılım mimarisi için geçerlidir: aptal olmayın. Ölçeklenebilirlik gerçekten gerekliyse, bunları da uygulamalısınız ve elbette darboğaz yüklememelisiniz.
- Teknolojik bağımsızlığın amacı genellikle soyutlamaların ve dolayların somut bir uygulamadan bağımsız olarak kurulduğu anlamına gelir. Genellikle sınırlıdırlar, çünkü olası tüm uygulamaların en küçük ortak paydasını uygulamalıdırlar. Çoğu zaman somut bir uygulama bile belirli bir noktada gibi görünmektedir, böylece gerçek bağımsızlık elde edilmez. Ve son olarak, teknolojik bağımsızlık ancak yeni bir teknoloji kullanılması gerekiyorsa öder. O zamana kadar, daha büyük karmaşıklıkla “ödemelisiniz”. Bu, sonunda en kolay yol olmamalıdır. Bağımlı teknolojiyi uygulamak ve teknolojiyi tam olarak kullanmak genellikle daha iyidir. Sadece başka bir teknoloji kullanılması gerektiğinde, sistem karmaşıklık maliyetleri için dönüştürülecek ve ödenecek. Farklı teknolojilerle oldukça kolay uygulanabilmeleri için bileşenleri küçük tutabilirsiniz.
- Başka bir örnek standardizasyon ve standardizasyondur. Bu kesinlikle bir verimlilik kazançına dönüşür, ancak bir şirketin BT panoramasına veya sadece bir projede kullanılan kütüphanelere bakarsanız, genellikle kaotik bir resim vardır. Bu kesinlikle optimal değil, ama aynı zamanda bu sorunu çözmek için yeterince insanı denediler ve başarısız oldular. Orada hizalanabilir veya sadece şirket gibi bazı yönleri standartlaştırabilirsiniz.
TL; Dr.
Bu yüzden yazılım mimarisi gelişir, neyin işe yaramadığına veda etmeliyiz. Ama o kadar kolay değil, çünkü ilkeler artık kırılması gereken bir gelenek.
()