Mimariler ve Mimari Paternleri
Bu konularda da Martin Fowler takipcisi olmak faydalı olacaktır.
Mimariler
Mimari olarak genelde iki tip tasarımla karşı karşıya kalırız. Monolithic ve Service-Oriented olarak karşımıza çıkmaktadır. Zaman ve paranın önemli olmadığı proje yok ama gerçekten de kaynakların sınırlı olduğu projelerde katmanlı mimari ve library temelli bir yapıyı tercih etmek faydalı olacaktır. Daha sonra ileri de hazırladığınız library leri servislere dönüştürmeyi planlayabilirsiniz.
Tasarımlarınızın decoupled olması ve implementation swap olması önemlidir. Böylece birbirleri arasındaki bağımlılığı azaltarak rahatça bir modülünüzü değiştirebilirsiniz. Hatta bir den fazla yazılım geliştiricisinin birlikte rahat paralel olarak geliştirme yapmasını da sağlar.
Yazılımda broker kavramı: Birden fazla iş alır ve bunu başkalarına sunar.
Alttaki mimari örneğinde Frontend deki istekleri dönüştüren bir WebAPI yazıyor (Presentation API) ve bunun içerisinde yapılacak işe ait logic bulundurmuyor. Gelen verinin modellere bind edilmesinden sorumlu. Asıl lojik arkadaki API Logic kısmında tutuluyor.
Projelerde her bir komponent 3 proje bileşenden (library, dll) oluşturmak iyi bir bölümlendirme getirir. Bunlar Interface, Implementation ve Test projeleridir.
Yazılımlarda Security kısmını lojikten ayrı tutmanın faydası ileride authentication ve authorization yönteminizi değiştirmenizde fayda sağlaması olacaktır.
Bu katmanlı ayrım sonrasında componentlerinizi yavaş yavaş servislere çevirebilirsiniz. Örneğin DataStorage de MongoDB update() metodunuzu daha sonrasında HTTP post çevirerek uzakdaki bir servis ile database yazma işlemine çevirebilirsiniz. Hatta trafiğiniz çok yüksek ise bir den fazla database servis kullanıp araya load balancer ekleyerek trafiği dağıtabilirsiniz. HTTP dışında başka interface olarak JSON, AMQP, XML, SOAP, FTP, CSV vs kullanılabilir.
Dependency Injection kullanarak proje çok flexiable bir şekilde yazılmış olunur. Her katman bir diğerinin sadece interface' ine bağımlı olduğu için implementation değişmesine bağımlı olmamış olacak. AutoFac, Ninject gibi IoC toollar kullanılarak bağımlılıkların ayarlanması da sağlanmış olunur. AutoFac daha hızlı bir tool.
Deployment da kolaylaştıran bir yapı sunmuş oluyorsunuz. Tüm ürünü değiştirmek yerine sadece bir library (dll vs.) değiştirerek müşterilerinizde güncelleme yapmış olabiliriz.
Tier ve Layer Kavramları
Tier refers to some physical separation while a layer is more of a logical separation
N-tiered refers to the "distributed" layers of a system (i.e. server and client), whereas n-layered refers to the layers in a self-contained program.
A layer = a part of your code, if your application is a cake, this is a slice.
A tier = a physical machine, a server.
N-Tier (Çoklu Katmanlı Mimari - Multi-Tier/Multi-Layered Architecture)
En çok bilinen 3 katmanlı yapı kullanımıdır. DAL, BL, PL olarak adlandırılırlar.
Database Layer (DL)
Veriler database de olduğundan uygulamaya bunların çekilmesi yerine DB server da yazacağınız scriptlerle iş yükünü orada bırakabilirsiniz. Network trafiği de çok olmaz. Ancak veri tabanı değişimlerinde orada yaptığınız değişimler yenisinde de yapılmak zorunda olacak.
Veri tabanlarından tek tek sorgu yapılacağına Bulk olarak veri çekilmelidir. I/O gecikmelerini azaltmış olursunuz.
Diğer üst 3 katman aynı dille yazılan monolitik bir uygulamanın katmanlarıdır
Data Access Layer (DAL)
Buradan direkt olarak veri kaynağınıza ulaşan kodlarınız olur. Database rahatça değiştirmenizi sağlayan bir katmandır. Örneğin MySQL ile geliştirme yaparken bir süre sonra kolay bir değişimle PostgreSQL geçebilirsiniz. Örneğin: C# için Entity Framework
Business Layer (BL, BLL)
İş ile ilgili algoritmalarınız olduğu bölümdür. Verilerin işlenip sunumlaştırma katmanına yönlendiren katmanınızdır. Kendi içerisinde de yatay katmanlar tasarlayabilirsiniz. Böylece her bir lojiğinizi ayrı proje veya library dönüştürebilirsiniz. Bunları daha sonra başka projelerinizde kullanabilirsiniz. Kısaltmalarda BLL (Business Layer Logic) diye de adlandırılır.
Presentation Layer (PL)
Kullanıcıların gördüğü kısımdır. Burada bir mantık içermemelidir. Sadece kullanıcan bilgi almak ve göstermek olmalıdır. Alınan girdinin valid olup olmadığına bakmak dahi bu katmanın işi olmamalıdır. Yoksa yeni bir UI ortamına geçtiğinizde bu lojik orada tekrar yazılması gerekecektir. Örneğin : Web Forms, HTML, WPF, Windows Form, Silverlight (2020 sonlarında sonu gelen bir teknoloji) vs..
Service Oriented Architecture (SOA)
Layer yapıda katmanlar arasında bir assembly geçiyorduk ancak burada bir servis oluyor. SOAP veya Restfull Servis gibi. Artık bir uygulama değil servisler açılır. Birbirlerine JSON gibi formatlarda veri göndererek ciddi bir ayrışma getirir. Teknoloji çeşitliliği de açar. WCF (Windows Communication Foundation), ZATO (https://zato.io/), Azure Service Bus, IBM App Connect, örnek verilebilir.
Microservice
Bu konuyla ilgili ayrı bir başlığımız var.
Küçük, bağımsız, otonom, diğer mikroservislerle sıkı sıkıya bağımlılığı bulunmayan, tek başına çalışabilen, kendine ait veri tabanı olan, geliştirme sürecinden kuruluma kadar bağımsız olan, yatayda ve dikeyde kendi başına ölçeklenebilen uygulamalara denir.
Farklı teknojileri bir araya getirebilme gibi bir çok avantajı olsa da kendisiyle birlikte problemler de getirmektedir.
Domain Driven Programming (DDD)
N-Tier mimari üzerinden devam eden alt katmanların oluşturulması (handle) sürecinde kendini göstermektedir.
Domain içinde bulunduğunuz kısıtlı bir yer.
Domain knowledge, proje bilgisi demektir. Bu projeyi kime, hangi endüstriye yapılıyorsunuz. Bu endüstride istenilenler (requirements) nelerdir? Nasıl işler yürüyor? Ne bekliyorlar ne görmek istiyorlar? gibi bilgiler domain bilgisi içerisine giriyor.
DDD de kod sisteminizi design etmez istenilen şeyler sisteminizin nasıl gelişeceğine karar verir.
Kodumuzda herkese kullanıcı demek yerine domain lere göre kullanıcıların tanımları yapıldığı bir yapı kurgulanır. Örneğin şirket düşünüldüğünde domainlerimiz ve kullanıcılarımız aşağıdaki gibi olmaktadır.
Domains: Satış, Marketing, Human Resources
Users : Human Resource -> Çalışanlar, Market -> Potansiyel Müşteriler, Satış -> Müşteriler
Daha gerçek hayata uygun mimari oluşmuş oluyor.
Aspect Oriented Programlama
Fonksiyonel olmayan kodlara örnek olarak logging, caching ve transactingi gösterebiliriz. Peki Aspect Oriented programlama(AOP) nedir? Aslında AOP’un bize söylediği şey, fonksiyonel olmayan ihtiyaçların aspect attributelar içerisine alınıp fonksiyonun içerisinde sadece fonksiyonel olan kodları bırakmak bu sadece daha temiz ve okunaklı fonksiyonlar elde etmektir.
Test Driven Programming
Polyglot Programming and Persistence
Mikroservis mimarileri, her servisin aynı veritabanı teknolojisinin farklı örnekleri veya tamamen farklı veritabanı sistemleriden oluşan ve adına Polyglot Persistence denen yaklaşımı kullanır.
Java securing API konusunda iyi bir seçenek olduğu belirtilmiş. Scala nın yavaş olduğundan bu amaçla kullanılmamasını tavsiye etmişler. Scala realtime stream processing de iyi build in olarak hazır olduğunu da belirtiyorlar. Python text analizinde iyi olduğu da belirtilmiş.
Design Patterns
Anti-Pattern tavsiye edilmeyen pattern demek. Nasıl ki pattern dediğimizde denenmiş ve zamanla kalitesi kanıtlanmış kod tasarımları diyorsak, anti-pattern ise bunların tam tersi etki yapacak olan pattern demek.
2020
Last updated
