OutSystems Mimarisi Neden Önemlidir ve Nasıl Olmalıdır?

OutSystems, web ve mobil uygulamalar oluşturmak ve yayınlamak için low-code ile geliştirme yapabileceğiniz bir platformdur. OutSystems mimarisi uygulamamızın nasıl çalışacağını ve performans göstereceğini belirleyen etkenlerden birisidir bu yüzden geliştirdiğimiz uygulamanın iyi bir mimariye sahip olması önemlidir. İyi bir mimariye sahip uygulama, uygulamanın kullanılabilirlik, işlevsellik, verim, sürdürülebilirlik, taşınabilirlik ve güvenilirliğini arttırır.

Kötü bir mimariye sahip uygulamada iş konseptleri doğru bir şekilde izole edilmemiş ve soyutlanmamıştır. İş kuralları farklı sistemlere yayılmıştır ve kodların yeniden kullanımı çok azdır veya hiç yoktur. Bunun yanı sıra sistemler birbirinden izole değildir ve bir sistemde güncelleme yapılması veya sistemin değiştirilmesi, diğer sistemler üzerinde de etkiye sahiptir.

İyi Bir mimariyle geliştirilmiş bir uygulamada birden fazla kişi çalışması veya başka birisinin uygulama üzerinde çalışması durumunda anlaşılabilirliği arttırır, problemleri kolayca saptamamızı ve kısa sürede çözüme kavuşturabilmemizi sağlar, uygulamanın mevcut halini bozmadan kolayca yeni özellikler ve yetenekler ekleyebiliriz ve uygulamanın bakımını kolaylaştırır. Bu uzun vadede kaynaklardan ve zamandan tasarruf etmemizi sağlar.  Kısacası fikir birliği sağlar, planlamayı destekler, karmaşıklığı yönetilebilmesini kolaylaştırır, değişim yapılmasını kolaylaştırır, riski azaltır ve maliyetleri düşürür.

Mimari yapımızı oluşturmak için OutSystems içerinde adapte edilmiş bir şekilde gelen Architecture Canvas Framework’unu kullanıyoruz. Bu framework mimari tasarımı hızlandırmak için bize sistematik bir yaklaşım sağlar. Burada üç katmandan oluşan çok katmanlı bir yapı kullanıyoruz. Bunlar sırasıyla End-User, Core ve Foundation. Core ve Foundation katmanlarında yeniden kullanılabilir servisleri bulunduruyoruz. End-User katmanında bir servis olmamalıdır. Eğer bu katmanları dahada genişletmek gerekirse. Foundation katmanı tüm yeniden kullanılabilir, fonksiyonu olmayan modülleri barındırır. Örnek olarak dışarıya bağlı sistemlere bağlantılar, kütüphaneler, yeniden kullanılabilir UI modülleri veya tema dosyalarını verebiliriz. Core katmanında ise core business servislerini dahil edeceğiz. Burada business kulları ve dependencies gibi business kavramları bulunur. End-User kısmında herhangi bir servis olmamalıdır. Burada kullanıcı arayüzleri, processler gibi kullanıcı etkileşimi bulunduran kısımları bulunduracaksınız.

Bu framework’u kullanmamızın nedenleri ise öncelikle bizi yeniden kullanılabilir servislerin ve komponentlerin soyutlanmasına teşvik eder. Dependencies arasındaki bağlantıları anlamak ve net bir şekilde tanımlayabilmek, lifecycle bağımsızlığını optimize etmeye yardımcı olur. Son olarak yapılan değişikliklerin sistemin çalışmasına olan etkisini minimuma indirir. Buda daha kolay bir bakım yapabilmek ve daha verimli değişiklikler yapabilmemiz için önemlidir.

Mimariyi tasarlamaya geldiğimiz zaman, mimari tasarım için 3 adım bulunur bunlar Disclose(İfşa Etmek), Organize(Düzenlemek) ve Assemble(Birleştirmek)’dir.

İlk adım, yani Disclose adımı iş kavramlarının, entegrasyon ihtiyaçlarının ve işlevsel olmayan gereksinimlerin açıklandığı yerdir. İlgili kullanıcıların ne gibi işlemler yapacaklarını belirlemek burada yardımcı olabilir. Kimin uygulama ile etkileşime gireceği veya uygulamaya erişebileceği, hangi kullanıcıların ve roller hangi işlemleri gerçekleştirebileceğini anlamak burada cevaplamamız gereken önemli sorulardan bir tanesidir. Geliştirme sürecinde hangi teknolojileri entegre edeceğimizi de bu aşamada belirlemeliyiz. Burada dikkat etmemiz gerek bir diğer konu ise kullanıcı deneyimi. Örnek olarak uygulama sadece mobil tabanlı veya web tabanlı mı olacak. Buradaki işimiz bittikten sonra ikinci adıma geçebiliriz. Organize, Düzenleme adımında belirlediğimiz aşamaların Architecture Canvasda hangi kısımda olduklarını belirleyip onları yerleştirmemiz gerekiyor. Bu adımda gereken kısımlarda Disclose adımına geri dönerek yeni kavramlar ekleyebiliriz. Üçüncü ve son adım ise kavramların modüller halinde bir araya getirildiği kısımdır. Burada uygulamamız gereken bazı prensipler bulunmaktadır. Birbirleriyle bağlantılı olan modüller birleştirilmelidir. Örnek olarak Müşteri ve Talep modülleri birbirleriyle bağlantılı ise tek bir modül içerisinde birleşmelidir. Birbirinden bağımsız bir lifecycle’ye sahip modüller bağlantılı olsalar bile birbirlerinden ayırılmalıdır. Örneğin Müşteri ve Sözleşme modülleri birbirleriyle bağlantılı olabilir fakat bazı müşterilerin bir sözleşmeye sahip olmaması gibi durumlarda birbirlerinden ayrı çalışan lifecycle’lara sahipler demektir. Bu gibi durumlarda modüller ayrı olmalıdır. Modüllere uygun olan tasarım desenlerini uygulamalıyız. Eğer yeni konseptler eklememiz gerekiyor ise en başa dönerek tüm adımları tekrar uygulamalıyız.