Teklif al

Sistem Mimarisi · Şişli

Şişli markaları için Sistem Mimarisi

Şişli'nin Nişantaşı ve Teşvikiye hattında marka katları yoğun. Karşılama masanız tekse kat akşam kapandığında o masa da kapanıyor; kurulu bir cihazın arızası ise kapanış saatini tanımıyor. Aynı numaraya iki ayrı cinsten istek düşüyor: henüz cihaz almamış tarafın mekân için istediği ölçü ve kurulumu bitmiş tarafın bakım kaydı. Mimari soru burada başlıyor. İki istek tek kayıt tipinde mi toplanacak, yoksa şemada baştan ayrılacak mı? Diotek'te bu ayrım ekranda değil, isteğin yazıldığı kayıt tipinde kuruldu.

Sistem Mimarisi — Şişli

Şişli'de kozmetik perakendesi ile merkezî ticaret aynı hatta duruyor. Marka vitrininiz hem henüz cihaz almamış tarafı hem kurulumu bitmiş tarafı aynı sayfaya getiriyorsa siteye düşen isteğin cinsi baştan belli olmuyor. Bu çalışma koşuluna en yakın işimiz Diotek. Örtüşmeyen yeri açık söylüyoruz: Diotek klima ve havalandırma firması için yazıldı; kozmetik perakendesinin ürün rafı, kampanya kurgusu ve mağaza kasası için gösterecek işimiz yok. Taşınan şey sektör değil karar: kaç uygulama kurulacağı, isteğin hangi şemada doğacağı, ilk sıcak günlerdeki yığılmayı hangi katmanın karşılayacağı koddan önce yazıya geçiyor. Yığın tarafı sabit: Laravel çekirdeği, MySQL kaydı, Redis okuma yükünü, Inertia arayüzü taşıyor.

  • Ölçü isteği ile servis kaydı şemada iki ayrı tip; operasyona ayrışmış ulaştıkları için serbest metin okuyup sıraya dizen bir kişiye ihtiyaç kalmıyor.
  • Tanıtım içeriği ve talep ekranı ayrı sistemlere bölünmedi: yönlendirmeyi ve doğrulamayı Laravel yapıyor, Inertia yalnız geçişi istemciye alıyor, içerik ile talep kaydı tek MySQL şemasında oturuyor.
  • Kat kapandıktan sonra gelen istek de yazılı geliyor; ertesi sabah kimin ne söylediği hatırlanmak zorunda kalmıyor.

Neden Algoriel

  • Parçalar aynı yerden okur

    Tahlil.com'da site, yönetim paneli ve mobil uygulama aynı bilgiyi okuyor; üçü ayrı sistem gibi davranmıyor.

  • Ne nerede çözülür, baştan belli

    Hangi işin hangi katmanda çözüleceğine kod yazılmadan karar veriliyor; sonradan yer değiştiren iş pahalıya geliyor.

  • Özet elle güncellenmiyor

    Günlük Hava Durumu'nda iklim özeti arşiv büyüdükçe kendini yeniliyor; kimse aylık tabloyu elle yazmıyor.

  • Dosya düzeni bir kurala bağlı

    KGM SsangYong'da dosyanın nereye ve hangi adla yazıldığı tek bir düzene bağlandı; yükleme kodu bu düzeni izliyor.

Ne inşa ediyoruz

Sistem Mimarisi
  • Verinin hangi sınırda duracağı

    Birden fazla kurumun aynı sistemi kullandığı kurulumda her kurum kendi alan adından girer; öğrenci, veli ve ödeme kaydı o kurumun sınırının içinde kalır. Bu düzene çok kiracılı kurulum deniyor.

  • Kaydın neye bağlanacağı

    Servis geçmişinin kişiye mi adrese mi cihaza mı yazılacağı koddan önce belirlenir. Bu karar sonradan değişirse o güne kadar biriken geçmişin tamamı yeniden bağlanır.

  • Yetkinin veri modelinde durması

    Öğretmen, veli ve kurum yöneticisi aynı ders programı kaydına kendi yetkisi kadar erişir. Yetki ekranda kapatılan bir görünüm değil, kaydın kendi tanımının parçası.

  • Okuma yolunun ayrılması

    Hangi ekranın hazır tutulan bir kopyadan, hangisinin doğrudan veritabanından okunacağı ilk kayıttan önce belirlenir. Vipkurum'da sık açılan ekran kopyadan geliyor, veritabanına yalnız kopyası olmayan okuma düşüyor.

  • Tek sisteme bağlanan arayüzler

    Tahlil.com'da üç arayüz tek sisteme bağlı: hasta sitesi, hekim paneli ve mobil uygulama aynı kaydı okuyor, arayüz başına ikinci bir veri modeli yazılmıyor.

  • Depolama düzeninin ilk günde kurulması

    Dosyaların hangi adlandırma ve klasör düzeninde duracağı en baştan belirlenir; sonradan kurulan düzen taşıma işine dönüşür.

Buna benzer çalışmalar

Sistem Mimarisi · Vaka çalışması

Diotek — istek iki tipte açılıyor, tanıtım ile talep tek uygulamada kalıyor

Bir iklimlendirme firmasının sitesi. Oraya düşen istek tek cinsten değil: biri henüz cihaz almamış tarafın mekân için istediği keşif tarihi, öbürü kurulumu tamamlanmış cihaza açılan bakım ya da arıza kaydı. İkisi ayrı tip olarak kuruldu, kuyruk birleşmediği için operasyonda elle ayıklama adımı doğmuyor. Tanıtım içeriği ve talep ekranı aynı Laravel uygulamasında: yönlendirmeyi ve form doğrulamasını Laravel yapıyor, Inertia yalnız geçişi istemciye alıyor, içerik ile talep kaydı tek MySQL şemasında duruyor. İlk sıcak günlerde artan okuma yükünü Redis önbelleği aynı kod tabanı içinde karşılıyor.

Vaka çalışmasını okuyun →

Şişli ekipleriyle uzaktan çalışmak

Ofisimiz yok; bu şehirdeki işleri de uzaktan yürütüyoruz ve yerinde destek vermiyoruz. Ne yapıldığı ve neden öyle yapıldığı yazılı duruyor. Ortaklıkla geliştirdiğimiz işler proje sayfalarında işaretli.

  • İlk sürüm çalışan bir parçayla çıkar, ek yetenekler sonra eklenir.
  • Bildiğimiz müşterilerimizin tamamı Türkiye'de.
  • Kararlar yazılı duruyor, ilerleme çalışan ekranlardan görünüyor.

Sık sorulan sorular

  • Mimari kararı vermek için kaç uygulama kuracağımızı baştan bilmek şart mı?

    Şart olan uygulama sayısı değil, kayıt tiplerinin sayısı. Diotek'te önce isteğin kaç ayrı cinsten geldiği yazıldı; uygulama kararı ondan sonra çıktı ve tanıtım içeriği ile talep ekranı tek yerde kaldı.

  • Forma bir açılır liste koysak aynı ayrımı yapmaz mıyız?

    Yapmaz. Açılır liste ekranda duran bir etiket, ayrım ise kayıt tipinde. Etikete güvenen kurulumda yanlış seçilmiş tek satır iki kuyruğu birden karıştırıyor; tipler ayrıldığında öyle bir satır hiç doğmuyor.

  • Marka katımız akşam kapanıyor; mesai dışında gelen istek ne oluyor?

    Kayıt sitenin üstünde oluştuğu için hattın açık olmasına bağlı değil. Gece açılan bir bakım kaydı sabah masaya yazılı geliyor, sıralaması da geldiği tipe göre belli oluyor.

  • Şişli'deyiz, siz uzaktan çalışıyorsunuz. Mimari kararı nasıl veriyorsunuz?

    Fiziksel ofisimiz yok, tamamen uzaktan çalışıyoruz. Verdiğimiz şey ziyaret değil yazılı çıktı: kayıt tipleri, şema sınırı ve okuma yolu. Formdan gelen mesajlara 2 iş günü içinde dönüyoruz.

Verinin hangi sınırda duracağına koddan önce karar verelim.