Hexagonal Mimari ile Ödeme Sistemleri Yazmak
İçindekiler
Craftgate
Craftgate, Türkiye’deki tüm bankaların Sanal POSlarını (Vpos), ödeme ve e-para kuruluşlarını tek merkezden yönetmenizi sağlarken, APM (Alternatif Ödeme Yöntemleri) ve yurtdışı ödeme entegrasyonları gibi alternatif ödeme kanallarından da ödeme almanıza aracılık eden bir ödeme geçididir. (hub, gateway).
Craftgate’in tanıdığı karekodla ödeme alma, kapalı devre cüzdan, akıllı ve dinamik ödeme yönlendirme gibi birçok katma değerli servis de eş zamanlı olarak kullanılabilir.
Ödeme Sistemleri
Ödeme sistemleri ve ödeme geçidi çok niş ve uzmanlık gerektiren alanlar. Aynı zamanda, paraya dokunulduğu için titizlik gerektiren ve minimum hatayla yönetilmesi gereken süreçler. Tabiri caizse paranın etrafında sihirbazlık yapıyorsunuz ve milyarlarca liralık işlemlerin geçtiği bir sistemde kuruşu kuruşuna her şey doğru olmalı.
Business’ın gerektirdiği ince işçilik ve titizlik nedeniyle Craftgate ödeme geçidini Hexagonal mimari ile yazma kararı almıştık. Bu kararı almamızdaki en önemli sebepler kısaca şu şekildeydi:
- Ödeme, doğası gereği karmaşık ve ağır bir domaine sahip. Bu nedenle domain kodunu olabildiğince anlaşılır, test edilebilir ve bakımı yapılabilir kılmak istiyorduk.
- Birçok farklı ödeme kanalından ödemeye aracılık ettiğimiz için entegrasyon noktalarımız epey farklılaşabiliyordu. (Rest, Soap, 3rd library vs.) Bu nedenle, çok farklı entegrasyonları dahi kolayca sisteme entegre edebilmeliydik.
- Kullandığımız framework ve kütüphanelerin olabildiğince güncel/güvenli sürümlerini kullanmaya özen gösterdiğimiz için buradaki herhangi bir değişikliğin domain kodunu bozmamasını ve etkilememesini istiyorduk.
- Business kodunu ayağa kaldırırken, teknik kararları olabildiğince erteleyebilmek istiyorduk.
- Değişme sıklığı çok olan kod ile az olan kodu birbirinden ayırmak istiyorduk.
- Ekibe yeni katılanların ödeme sistemlerini ve code base’i kolayca anlayabilmelerini istiyorduk.
Elbette, yukarıdaki sebepleri daha da çoğaltabiliriz.
Hexagonal mimari her business için veya her aşama için anlamlı olmayabilir, bazı business’lar için hiç gerekmeyebilir yada erken aşama için daha farklı mimariler tercih edilebilir.
Biz bu kararı alırken hem geçmişteki ödeme sistemleri deneyimlerimizden yola çıktık hem de diğer yazılım geliştirme mimarilerindeki tecrübelerimizi göz önünde bulundurduk. İlk yazdığımız versiyon üzerinden neredeyse 3-4 kez refactor etmiş ve evriltmiştik. Üzerinden yıllar geçtikten sonra bu kararın bize çok şey kattığını söyleyebiliriz.
Hexagonal Mimari
Hexagonal mimariyi en temelde domain ve infra olmak üzere 2 birime ayırıyoruz.
Domain, business’ın sağlıklı ve doğru büyümesini sağlayan, gerçek anlamda iş kodunu barındıran ve bizim en çok önem verdiğimiz birimdir. Ödeme dünyasında domain, komisyon hesaplamaları ve satıcı hakedişlerin hesaplanıp gönderilmesi gibi business’ın çekirdeğini oluşturan konuları içerisinde barındırır.
“Payment is our business, and business is good.”
Infra ise tamamen framework ve teknolojik kodları barındıran birimdir. Ödeme alma için açtığımız rest endpointler, db/redis gibi detaylar burada yer alır.
İki birimin de kendine has dinamikleri ve çalışma şekli vardır.
Genel hatlarıyla, kullandığımız Hexagonal Mimariyi aşağıdaki gibi özetleyebiliriz;
Domain kodlarımızda teknoloji veya framework bağımlı herhangi bir class/annotation vs. bulunmuyor. Dolayısıyla, domain tarafında core Java yazıyoruz diyebiliriz. Bu durum, domain’i kendi başına test edilebilen, okunabilen ve anlaşılabilen kod parçacıklarına dönüştürüyor. Burası business driven, yani şirketin gitmek istediği yöne göre pivot edebilen, iş kararlarının uygulandığı birimdir. Dolayısıyla bir t anında değişebilir, evrilebilir.
Infra kodlarımız ise tamamen teknoloji odaklı, rest servislerin bulunduğu, veritabanı işlemlerinin vs. olduğu ve domaini tetikleyen yer. Genelde değişme sıklığının az olduğu yerler diyebiliriz. Açtığımız rest endpointler’in ilk günkü gibi hemen hemen aynı olduğunu söyleyebiliriz.
Hexagonal mimariyi seçmemizdeki en büyük nedenlerden biri de yukarıda ifade ettiğimiz gibi sıklıkla değişebilecek kodları daha az değişen kodlardan ayırabilmekti. Bunun canlı örneğini geleneksel ElasticSearch yerine AWS’in OpenSearch servisini kullanmaya karar verdiğimizde tekrar görmüştük 🙂 . Kod içerisinde sadece tek bir class değiştirerek bu değişimi sağlayabilmiştik. Domain kodumuzda ise hiç değişiklik olmamıştı.
Günün sonunda Hexagonal Mimari birçok anlamda hayatımızı kolaylaştırdığını rahatlıkla söyleyebiliriz. Bu faydaları şöyle özetleyebiliriz:
- Ağır bir domain olan ödeme sistemlerini, anlaşılır ve yönetilebilir kılabiliyoruz.
- Yeni entegrasyon uçlarını sisteme kolayca ekleyebiliyoruz. Bunlar yeni bir banka Sanal POS’u da olabilir, yurtdışı ödeme yöntemlerinden biri de olabilir.
- Domain üzerine kolayca tartışma yapabiliyoruz.
- Domaini kendi başına test edip, business’i validate edebiliyoruz.
- Ekip içerisinde know-how çok daha kolay ve hızlı yayılabiliyor.
- Pull requestlerde ve reviewlarda domain kodundaki değişiklikleri/kararları çok daha net görebiliyoruz.
