paint-brush
En İyi Karmaşık Ön Uç Mimarisi: Özellik Dilimli Tasarım Hakkında Bilmeniz Gerekenlerile@mmmidas
1,942 okumalar
1,942 okumalar

En İyi Karmaşık Ön Uç Mimarisi: Özellik Dilimli Tasarım Hakkında Bilmeniz Gerekenler

ile Yan Levin8m2024/01/18
Read on Terminal Reader
Read this story w/o Javascript

Çok uzun; Okumak

Bu makale Özellik Dilimli Tasarım mimarisini tartışıyor, çünkü bence mevcut seçenekler arasında en iyisi. Aynı zamanda FSD fikrini ve bu mimari metodolojinin çözdüğü sorunları da araştırıyor.
featured image - En İyi Karmaşık Ön Uç Mimarisi: Özellik Dilimli Tasarım Hakkında Bilmeniz Gerekenler
Yan Levin HackerNoon profile picture
0-item
1-item
2-item

giriiş

Ön uç geliştiriciler sıklıkla uygulama mimarisiyle ilgili bir sorunla karşı karşıya kalır. Kolayca ölçeklenebilen, uygulama modülleri arasında gevşek bağlantı ve yüksek uyum sağlayan bir mimarinin kullanılmasını gerektirir.


Bu makale Özellik Dilimli Tasarım mimarisini tartışıyor, çünkü bence mevcut seçenekler arasında en iyisi. Aynı zamanda FSD fikrini ve bu mimari metodolojinin çözdüğü sorunları da araştırıyor.


FSD'yi klasik ve modüler mimarilerle karşılaştırıp artılarını ve eksilerini inceleyeceğiz.


Öncelikle üç kavramı birbirinden ayıralım: katman, dilim ve segment.

Katmanlar, Dilimler, Segmentler

Katmanlar

Katmanlar, üst düzey dizinlerdir ve uygulama ayrıştırmasının ilk düzeyidir. Sayıları sınırlıdır (maksimum 7 katman) ve standartlaştırılmıştır, ancak bazıları isteğe bağlıdır.


Şu anda aşağıdaki katmanlar ayırt edilmektedir:

Katmanlar Her katmanın kendi sorumluluk alanı vardır ve iş odaklıdır. Her katmanı ayrı ayrı ele alalım.


  • app: Burası uygulama mantığının başlatıldığı yerdir. Sağlayıcılar, yönlendiriciler, global stiller, global tür bildirimleri vb. burada tanımlanır. Uygulama için giriş noktası görevi görür.


  • işlemler: Bu katman, çok adımlı kayıt gibi birden çok sayfaya yayılan işlemleri yönetir. Bu katmanın kullanımdan kaldırıldığı kabul edilir ancak yine de ara sıra karşılaşılabilir. İsteğe bağlı bir katmandır.


  • sayfalar: Bu katman uygulamanın sayfalarını içerir.


  • widget'lar: Bunlar sayfalarda kullanılan bağımsız kullanıcı arayüzü bileşenleridir.


  • Özellikler: Bu katman, iş değeri taşıyan kullanıcı senaryoları ve işlevlerle ilgilenir. Örneğin beğeniler, yorum yazma, ürünleri derecelendirme vb. İsteğe bağlı bir katmandır.


  • varlıklar: Bu katman ticari varlıkları temsil eder. Bu varlıklar kullanıcıları, incelemeleri, yorumları vb. içerebilir. Bu isteğe bağlı bir katmandır.


  • paylaşılan: Bu katman, belirli iş mantığına bağlı olmayan yeniden kullanılabilir bileşenleri ve yardımcı programları içerir. Bir UI kiti, Axios yapılandırması, uygulama yapılandırması, iş mantığına bağlı olmayan yardımcılar vb. içerir.


Bu katmanlar kod tabanının düzenlenmesine yardımcı olur ve modüler, bakımı yapılabilir ve ölçeklenebilir bir mimariyi destekler.

Github Katmanları

Özellik Dilimli Tasarımın temel özelliklerinden biri hiyerarşik yapısıdır. Bu yapıda, özellikler hiyerarşide daha yüksek olduğundan varlıklar özelliklerin işlevselliğini kullanamaz.


Benzer şekilde, yukarıdaki katmanlar yalnızca aşağıdaki katmanları kullanabileceğinden, özellikler widget'lardan veya işlemlerden gelen bileşenleri kullanamaz. Bu, yalnızca bir yöne yönlendirilmiş doğrusal bir akışı korumak için yapılır. Katman Yapısı Bir katman hiyerarşide ne kadar düşük konumlandırılırsa, kodda daha fazla yerde kullanılması muhtemel olduğundan üzerinde değişiklik yapmak o kadar riskli olur. Örneğin, paylaşılan katmandaki kullanıcı arayüzü kiti özelliklerde, widget'larda ve hatta sayfa katmanlarında kullanılır.

Dilimler

Katmanların her birinde, uygulama ayrıştırmasının ikinci düzeyi olan alt dizinler (dilimler) vardır. Dilimlerde bağlantı soyut şeylerle değil, belirli ticari varlıklarladır. Dilimlerin temel amacı kodu değerine göre gruplamaktır.


Dilim adları doğrudan projenin iş alanına göre belirlendiğinden standartlaştırılmamıştır. Örneğin bir fotoğraf galerisinde fotoğraf, albüm, galeri gibi bölümler olabilir. Bir sosyal ağ, gönderiler, kullanıcılar ve haber akışları gibi dilimler gerektirir.


Yakından ilişkili parçalar bir dizinde yapısal olarak gruplandırılabilir, ancak diğer dilimlerle aynı izolasyon kurallarına uymaları gerekir; bu dizindeki koda paylaşılan erişim olmamalıdır.

Dilimler

Segmentler

Her dilim segmentlerden oluşur. Segmentler, kodun amacına göre bir dilime bölünmesine yardımcı olur. Ekibin anlaşmalarına bağlı olarak segmentlerin kompozisyonu ve isimlendirmesi değişebilir. Aşağıdaki segmentler daha yaygın olarak kullanılmaktadır:


  • api - gerekli sunucu istekleri.


  • UI - dilimin UI bileşenleri.


  • model - İş mantığı, yani devletle etkileşim. Örneğin, eylemler ve seçiciler.
  • lib - dilim içinde kullanılan yardımcı işlevsellik.


  • config - dilimin gerekli konfigürasyonu, ancak config segmentine nadiren rastlanır.


  • consts - gerekli sabitler.

Genel API

Her dilim ve segmentin bir Genel API'si vardır. Genel API, dilim veya segmentten yalnızca gerekli işlevlerin dışarıya çıkarılmasına ve gereksiz işlevlerin yalıtılmasına olanak tanıyan bir index.js veya index.ts dosyasıyla temsil edilir. İndeks dosyası bir giriş noktası görevi görür.


Genel API Kuralları:


  • Uygulama dilimleri ve segmentleri, dilimin yalnızca Genel API dizin dosyasında tanımlanan işlevlerini ve bileşenlerini kullanır.


  • Genel API'de tanımlanmayan dilimin veya segmentin dahili kısmı izole edilmiş olarak kabul edilir ve yalnızca dilimin veya segmentin kendi içinden erişime açıktır.


Genel API, içe ve dışa aktarma işlemleriyle çalışmayı basitleştirir; böylece uygulamada değişiklik yaparken, içe aktarma işlemlerini kodun her yerinde değiştirmenize gerek kalmaz.

Genel API

Mimarinin Daha Derinlerine

Soyutlama ve İş Mantığı

Katman ne kadar yüksek olursa, belirli iş düğümüne o kadar bağlı olur ve daha fazla iş mantığı içerir. Katman ne kadar düşük olursa, katmanda o kadar fazla soyutlama, yeniden kullanılabilirlik ve özerklik eksikliği olur.

Katmanların Soyutlanması

FSD Sorunu Nasıl Çözüyor?

Özellik Dilimli Tasarımın görevlerinden biri gevşek bağlantı ve yüksek uyum sağlamaktır. FSD'nin bu sonuca nasıl ulaştığını anlamak önemlidir.


OOP'ta bu sorunlar uzun zamandır polimorfizm , kapsülleme , kalıtım ve soyutlama gibi kavramlarla çözülmüştür. Bu kavramlar, bir bileşenin veya işlevselliğin nasıl kullanıldığına bağlı olarak farklı sonuçların elde edildiği kodun izolasyonunu, yeniden kullanılabilirliğini ve çok yönlülüğünü sağlar.


Özellik Dilimli Tasarım, bu ilkelerin ön uçta uygulanmasına yardımcı olur.


Soyutlama ve polimorfizm katmanlar aracılığıyla elde edilir. Alt katmanlar soyut olduğundan üst katmanlarda tekrar kullanılabilir ve koşullara bağlı olarak bir bileşen veya işlevsellik, belirtilen parametrelere veya donanımlara göre farklı şekilde çalışabilir.


Kapsülleme , dışarıdan ihtiyaç duyulmayanları dilimler ve segmentler halinde izole eden Genel API aracılığıyla gerçekleştirilir. Bir dilimin iç bölümlerine erişim sınırlıdır ve Genel API, bir dilim veya bölümün işlevlerine ve bileşenlerine erişmenin tek yoludur.


Daha yüksek katmanlar alt katmanları yeniden kullanabildiğinden kalıtım katmanlar aracılığıyla da sağlanır.

Klasik Mimariyle Karşılaştırma

Sanırım klasik mimariye birçok kez rastlamışsınızdır. Çoğu yazar, basitliği nedeniyle bunu eğitim makalelerinde ve YouTube videolarında kullanır. Klasik mimarinin belirli bir standardı yoktur. Ancak sıklıkla aşağıdaki formatı görebilirsiniz:

Klasik Mimari Klasik mimarinin gözle görülür dezavantajları vardır. Bunlardan en büyüğü, bileşenler arasındaki örtülü bağlantılar ve modül karmaşası nedeniyle projenin sürdürülmesinin zorlaşmasıdır. Klasik mimarinin dezavantajları zamanla daha da belirgin hale gelir. Proje ne kadar uzun süre gelişirse, uygulama mimarisi de çözülmesi zor olan karmaşık bir karmaşaya dönüşür.


Klasik mimari, devam eden bakım veya evcil hayvan projeleri gerektirmeyen küçük projeler için uygundur.

Özellik Dilimli Tasarım, konseptleri ve standartları sayesinde klasik mimarinin sorunlarının önüne geçer.


Ancak FSD ile çalışan geliştiricilerin anlayış ve becerilerinin, klasik mimariyle çalışan geliştiricilerden daha yüksek olması gerekir. Genellikle 2 yıldan az deneyime sahip geliştiriciler FSD'yi duymamıştır.


Ancak, Özellik Dilimli Tasarımla çalışırken sorunların "daha sonra" yerine "şimdi" ele alınması gerekir. Koddaki sorunlar ve konseptlerden sapmalar hemen fark ediliyor

Basit Modüler Mimariyle Karşılaştırma

Basit modüler mimarinin çeşitli dezavantajları vardır:

  • Bazen işlevselliğin modüllere veya bileşenlere nereye yerleştirileceği açık değildir.


  • Başka bir modül içindeki modülleri kullanmanın zorlukları.


  • Ticari varlıkların depolanmasıyla ilgili sorunlar.


  • Küresel işlevlerdeki örtülü bağımlılıklar, karmaşık bir yapıya yol açıyor.


Herhangi bir karmaşık veya orta derecede karmaşık projede, basit modüler mimariye göre Özellik Dilimli Tasarımın tercih edilmesi gerektiği görülmektedir. FSD birçok temel mimari sorunu çözmektedir ve çok az dezavantajı vardır.


Basitlik ve geliştirme hızı açısından basit bir modüler mimarinin FSD'ye göre avantajı olabilir. Bir MVP'ye ihtiyaç duyuluyorsa veya kısa ömürlü bir proje geliştiriliyorsa, basit bir modüler mimari FSD'den daha uygun olabilir. Ancak diğer durumlarda, özellik dilimli bir tasarım tercih edilebilir görünüyor.

Özellik Dilimli Tasarımın Potansiyeli

FSD genç bir mimari metodolojidir. Ancak halihazırda birçok bankacılık, fintech, B2B, e-ticaret şirketi ve diğerleri tarafından kullanılıyor. İşte şirketlerin listesini içeren GitHub sayısının bağlantısı: GitHub Sayısı .


Resmi FSD belgelerini içeren GitHub deposu, bu makalenin yayınlandığı tarihte 1,1 binden fazla yıldıza sahipti. Belgeler aktif olarak genişletiliyor ve Telegram ve Discord'daki FSD geliştirme ekibi ve topluluğu, mimariyle ilgili sorularda insanlara yardımcı olmak için 7/24 hizmetinizde.


Bu mimarinin potansiyeli son derece kabul görmektedir ve kullanımı dünya çapında büyük şirketler arasında yaygın olarak yayılmaktadır. Doğru şekilde benimsenmesiyle FSD, ön uç geliştirme alanında baskın mimari çözüm olma potansiyeline sahiptir.

Mimarinin Avantajları ve Dezavantajları

Avantajları

  • Mimari bileşenler kolayca değiştirilebilir, eklenebilir veya kaldırılabilir


  • Mimarinin standardizasyonu


  • Ölçeklenebilirlik


  • Metodoloji geliştirme yığınından bağımsızdır.


  • Beklenmedik yan etkiler olmaksızın modüller arasında kontrollü ve açık bağlantılar.


  • İş odaklı mimari metodoloji.

Dezavantajları

  • Diğer birçok mimari çözümle karşılaştırıldığında daha yüksek bir giriş bariyeri.


  • Farkındalık, ekip kültürü ve kavramlara bağlılık gerektirir.


  • Zorlukların ve sorunların daha sonra değil, derhal ele alınması gerekir. Kod sorunları ve kavramlardan sapmalar hemen fark edilir. Ancak bu aynı zamanda bir avantaj olarak da görülebilir.

Çözüm

Özellik Dilimli Tasarım, ön uç geliştiricilerin bilmesi ve kullanabilmesi gereken ilginç ve değerli bir keşiftir. FSD, ekiplere esnek, standartlaştırılmış ve ölçeklenebilir bir mimari ve geliştirme kültürü sağlayabilir. Ancak metodolojinin olumlu yönlerinden yararlanmak ekip içinde bilgi, farkındalık ve disiplin gerektirir.


FSD, açık iş yönelimi, varlık tanımı, işlevsel bileşimi ve uygulamanın bileşen bileşimi nedeniyle diğer mimariler arasında öne çıkıyor.


Ayrıca projelerde FSD kullanım örneklerini ve resmi Özellik Dilimli Tasarım belgelerini bağımsız olarak keşfedebilirsiniz:


Resmi Belgeler

Örnek. GitHub İstemcisi

Örnek. Nike Spor Ayakkabı ve Ayakkabı Mağazası

Örnek. Sudoku


Bu yazı biraz uzun olabilir ama umarım yeni bir şeyler öğrenmişsinizdir. Bu yazıyı okumayı bitirdiğiniz için teşekkür ederim.


Herhangi bir düşünceniz veya sorunuz varsa, yorum bırakmaktan çekinmeyin!


Burada da yayınlandı