Yönetici portalları için mikro-frontend'ler: pratik karar rehberi

Yönetici portalları için mikro-frontend'lerin çözmeye çalıştığı sorun

Bir yönetici portalı nadiren sadece bir UI'dır. Zamanla veri ağırlıklı ekranlara (tablolar, filtreler, exportlar), operasyonel iş akışlarına (onaylar, iadeler, onboarding) ve sıkı izinlere (roller, denetim kayıtları, kim ne yapabilir) dönüşür. Ayrıca her dahili ekip bir düğme, bir sütun ya da bir kural daha ister.

Bu yüzden yönetici arayüzleri çok sık değişir. Destek daha hızlı ticket çözümü ister, finans yeni raporlar ister, operasyon istisna akışları ister, yöneticiler daha fazla görünürlük ister. Her talep küçük olsa bile portal paydaşların, teslim tarihlerinin ve önceliklerin kesiştiği yoğun bir kavşağa dönüşür.

Mikro-frontend'ler bu baskıya verilen cevaplardan biridir. Basitçe söylemek gerekirse, tek bir büyük frontend'i daha bağımsız çalışıp dağıtılabilecek küçük parçalara bölerler. Tüm değişikliklerin aynı build ve release üzerinden geçtiği tek bir kod tabanı yerine, Kullanıcılar, Faturalama, Envanter veya Raporlar gibi ayrı alanlar olabilir ve her biri farklı bir ekip tarafından sahiplenilir.

Gerçek karar her zaman bir takastır: bağımsızlık vs koordinasyon.

Bağımsızlık daha hızlı teslim ve net sahiplik anlamına gelebilir; çünkü takımlar birbirlerinin işine basmadan çalışabilir. Maliyet ise portalın tek bir ürün gibi hissetmesini sağlamak için gereken koordinasyondur: ortak navigasyon, tutarlı UI örüntüleri ve kimlik doğrulama, izinler, logging ve hata yönetimi gibi çapraz ihtiyaçlara temiz bir yaklaşım.

Eğer ana sıkıntınız “çok fazla ekip tek bir release hattı tarafından bloklanıyor” ise mikro-frontend'ler yardımcı olabilir. Eğer ana sıkıntınız “herkes temelde aynı konularda anlaşmak zorunda” ise mikro-frontend'ler bunu daha zor hale getirebilir.

Mikro-frontend'lerin genellikle işe yaradığı durumlar

Mikro-frontend'ler genellikle portal gerçekten giriş yapma ve menü paylaşan ayrı ürünlerden oluştuğunda en iyi şekilde çalışır. Bu durumda UI'yi bölmek genellikle işin zaten nasıl bölündüğüyle eşleşir.

En güçlü gösterge iş domaini sahibinin net olmasıdır. Faturalama (faturalar, planlar, iadeler) Destek'ten (ticket'lar, makrolar, müşteri geçmişi) veya Envanter'den (SKU'lar, stok hareketleri, tedarikçiler) farklıdır. Her alan farklı kurallar, veriler ve ekranlara sahipse sınır doğal olabilir.

Yayın takvimi de başka bir işarettir. Faturalama haftalık değişikliklere ihtiyaç duyarken Envanter aylık güncelleniyorsa, tek bir paylaşılan frontend release'ı sürekli bloklanmaya dönüşebilir. Ayrı dilimler, paylaşılan temeller kararlı kaldığı sürece kendi takvimlerinde gönderilebilir.

Ayrıca bir ekip kesimini uçtan uca destekleyebiliyorsa mikro-frontend'ler yardımcı olur: UI, API sözleşmeleri, analytics ve on-call düzeltmeler. Bunlar yoksa, genellikle koordinasyon işini bir yerden başka bir yere kaydırmış olursunuz.

Risk izolasyonu insanların ilk fark ettiği pratik faydadır. Bir domain yeniden tasarlanıyorsa veya hızlı değişiyorsa, onu izole etmek bir şeyler bozulduğunda etki alanını azaltır.

Eğer örgütünüz zaten şöyle görünüyorsa mikro-frontend'ler sürtünmeyi azaltma olasılığı yüksektir:

• Ayrı domainlere haritalanmış ayrı takımlar
• Birbirini engellememesi gereken farklı yayın takvimleri
• Domainler arasında net API sınırları
• Tek, kararlı bir ortak kabuk (navigasyon, auth, layout)

Mikro-frontend'lerin genellikle zarar verdiği durumlar

Mikro-frontend'ler gerçek bir ek yük getirir. Portalın çoğunu tek bir küçük ekip yönetiyorsa, onu birden çok front-end'e bölmek genellikle hızdan çok daha fazla koordinasyon yaratır. Parçaların tutarlı hissetmesi için ekstra işler yaparsınız.

Yaygın bir uyarı işareti yoğun paylaşılan UI örüntüleridir. Yönetici portalları sıklıkla aynı tablo düzenlerini, filtreleri, toplu işlemleri, izin banner'larını, denetim panellerini ve onay akışlarını yeniden kullanır. Her sayfa aynı yapı taşlarını gerektiriyorsa, birden fazla dilim ayrı düşebilir. Küçük farklar birikir ve kullanıcılar fark eder.

Ayrıca paylaşılan iş akışları sürekli değişiyorsa zorluk çıkarırlar. Aynı form veya onay akışı birçok alanda tekrar kullanılıyorsa, her değişiklik çok-takımlı bir release olur. Bir pull request yerine birkaçını yönetmek, artı tam yolun çalıştığını doğrulamak için ekstra test gerekir.

DevOps kapasitesi sessiz bir karar kırıcıdır. Daha fazla repo ve deployable daha fazla pipeline, versiyonlama, izleme ve rollback planı demektir. Ekip zaten gerginse, release'lara bakmakla uğraşmak portalı iyileştirmek yerine zamanınızı alabilir.

Hızla ortaya çıkan birkaç ağrı çarpanı:

• Çok sayıda paylaşılan bileşen ama güçlü bir paylaşılan tasarım sistemi ve yönetişim yok
• Her yerde aynı davranması gereken tek bir giriş ve izin modeli
• Domainleri geçen çok sayıda uçtan uca akış (örneğin: iade -> destek ticket'ı -> müşteri bildirimi)
• Paralel dağıtım yapma ve sorunları hızlı teşhis etme yeteneğinin sınırlı olması

Örnek: Küçük bir operasyon ekibi tüm ekranlarda aynı müşteri seçiciyi ve aynı vaka notları panelini kullanıyorsa, bu bileşenler mikro-frontend'ler arasında kopyalanırsa, doğrulama kurallarındaki basit bir değişiklik koordineli çoklu uygulama release'ına dönüşebilir ve ekip büyümeden portal yavaşlar.

Ekip sınırları: çizgileri belirlemenin basit yolu

Bir yönetici portalını ayırmanın en temiz yolu iş domainine göre yapmaktır, UI parçalarına göre değil. Bir domain kendi hedefleri, verileri ve kuralları olan bir iş parçasıdır (Kullanıcılar, Faturalama, Envanter, Destek). Düğmeler, tablolar veya "sol taraf vs sağ taraf" gibi parçalara göre ayırırsanız takımlar her hafta birbirinin üzerine düşer.

Her alan için faydalı bir soru: bir ekip sonucu uçtan uca sahiplenebilir mi? Ekranları, doğrulamaları ve API çağrılarını üç diğer ekibin her küçük değişikliği onaylamasına gerek kalmadan değiştirebilmeli.

Hızlı bir sınır testi

Portal sayfalarınızı listeleyin ve işin ne yaptığına göre gruplayın. Sonra her grubu kontrol edin:

• Domain kuralları nispeten stabildir.
• Ana veri ve kararların sahibi bir ekip var (gerçeğin kaynağı).
• Çoğu değişiklik domain içinde kalıyor.
• Paylaşılan parçalar küçük ve açık (auth, navigasyon kabuğu, roller ve izinler).
• Çapraz-domain değişiklikler için net bir sahip ve onay yolu var.

Eğer bir veri sahibi isimlendiremiyorsanız, sınır henüz gerçek değildir. Sürekli “Customer” düzenlemeleri gerektiren “Orders” genellikle erken veya yanlış yerde bölündüğünüz anlamına gelir.

Genellikle paylaşılması gerekenler sıkıcı ama önemlidir: giriş, oturum yönetimi, global navigasyon, izin kontrolleri ve temel layout. Bunları herkesin takip ettiği tek bir sözleşme olarak ele alın, yoksa her ekip bunları hafifçe yeniden uygular.

Hatta AppMaster gibi bir no-code araçla bir yönetici portalı inşa ediyorsanız bile bu kural geçerlidir: önce iş sahipliğini tanımlayın, sonra nasıl paketleyeceğinize ve dağıtacağınıza karar verin.

Paylaşılan tasarım sistemi: belirleyici faktör

Mikro-frontend'ler örgüt şemasında “mikro” hissedilir. Kullanıcılar için hala tek bir üründür. UI ekranlar arasında ince ince değişirse insanlar araca güvenmeyi bırakır, sadece tasarıma değil.

Her yerde aynı hissettirmesi gerekenleri önce kararlaştırın. Çoğu yönetici portalında bu sayfa düzeni, tablolar, filtreler, formlar, doğrulama ve hata mesajları ile sistem geri bildirimlerini (toasts, banner'lar, izin hataları) içerir.

Sonra takımların bu parçaları nasıl paylaşacağına karar verin. Paylaşılan bir bileşen kütüphanesi en iyi tutarlılığı verir, ancak koordinasyon ve yayın işi ekler. Bileşenleri her dilime kopyalamak ilk başta daha hızlı gelir, ama farklar çabucak birikir ve düzeltmeler tekrarlanır.

Paylaşılan bir kütüphane seçerseniz, onu öngörülebilir tutun. Tasarım token'larını (renkler, boşluk, tipografi), temel erişilebilirlik kurallarını (focus durumları, klavye desteği, kontrast) ve değişiklikleri kim onaylar konusunu tanımlayın. "Herkes düzenleyebilir" genellikle "hiç kimse sahiplenmiyor"a dönüşür.

Kırıcı değişiklikler işin acı verdiği yerdir. UI değişikliklerini ürün değişikliği gibi ele alın. Basit bir süreç şunları içerebilir:

• Paylaşılan kütüphaneyi versiyonlayın ve sürüm notları yayınlayın
• Kırıcı değişikliğin ne sayıldığında anlaşın
• Düzenli bir yükseltme penceresi belirleyin (örneğin iki haftada bir)
• Yeni bileşenler için hafif bir inceleme ekleyin

Eğer tablo bileşeni filtrelerin uygulanma şeklini değiştirirse, bir dilim bugün güncelleyebilir, diğeri gelecek ay. Kullanıcılar bu farklılığı tutarsızlık olarak deneyimler, hatta backend veriler doğru olsa bile.

AppMaster gibi bir platformda inşa ediyorsanız aynı ilkeyi uygulayın: bir set UI deseninde ve token'da anlaşın ve bunları ekranlar boyunca zorunlu kılın ki ayrı alanlar yine de tek bir araç gibi hissettirsin.

Mikro-frontend'ler nasıl bir araya getirilir (jargondan uzak)

Bir mikro-frontend kurulumunda bir portal, birkaç küçük frontend'den toplanır. Bölünme kendisi zor değil; zor olan kullanıcılar dolaşırken bütünün tutarlı davranmasını sağlamaktır.

Parçaları birleştirmenin iki yolu

İki yaklaşım en sık görülür:

Runtime composition: Portal parçaları çalışırken yükler. Bir shell uygulama çerçeveyi (navigasyon, layout) render eder ve bir takımın Users sayfasını, diğerinin Billing sayfasını çeker. Bu bağımsız deploy'lara izin verir ama runtime'da daha fazla hareketli parça ekler.

Build-time packaging: Her ekip bir parçayı inşa eder ama bunları birlikte (veya yakın zamanda) gönderirsiniz. İşletmesi genellikle daha basittir ve çoğu zaman daha hızlıdır, ama bağımsızlığı azaltır ve kaçınmaya çalıştığınız koordinasyonu geri getirebilir.

Routing bir çok projenin tökezlediği yerdir. URL haritasının kime ait olduğuna karar verin. Yaygın bir desen shell'in üst seviye rotaları (/users, /billing) sahiplenmesi ve her dilimin kendi iç rotalarına (/users/123) sahip olmasıdır. Ayrıca biri doğrudan bir alt sayfaya geldiğinde deep linklerin çalıştığından emin olun.

Tek bir portal gibi hissettirmek

Kullanıcılar sınırları fark etmemeli. Auth, roller, feature flag'ler ve temel UI davranışı için ortak kurallarda anlaşın.

Pratik bir tutarlılık kontrol listesi:

• Portal boyunca tek bir giriş akışı ve tek bir oturum modeli
• Roller ve izin kontrolleri için tek bir doğruluk kaynağı
• Gizli bir özelliğin her yerde gizli kalmasını sağlayan paylaşılan feature flag'ler
• Paylaşılan yükleme ve hata durumları
• Düğmeler, tablolar ve formların eşleşmesini sağlayan paylaşılan tasarım sistemi

Orders dilimi zaman aşımına uğrarsa, Support diliminin kullandığı geri dönüş stili ve kurtarma eylemi yerine custom bir mesaj göstermemeli.

Dağıtım karmaşıklığı: neye imza atıyorsunuz

Mikro-frontend'ler temiz bir bölünme gibi görünebilir, ama gönderip istikrarlı tutmanız gerekenleri çoğaltırlar.

Önce sayfaları değil pipeline'ları sayarak başlayın. Her dilim genelde kendi build, test, güvenlik kontrolleri, onaylar, izleme ve rollback planına ihtiyaç duyar. Beş dilim varsa, kabuk artı beş release hattınız olabilir.

Uyumluluk ve hata modları hakkında erken kararlar verin. Monolitikte bir şeyi geri alırsınız. Mikro-frontend'lerde yeni bir shell eski bir dilimle çalışmak zorunda kalabilir veya tam tersi. Bu ancak net sözleşmeler, geriye dönük uyumlu değişiklikler ve kod+konfigürasyon için rollback planı ile çalışır.

Performans için yazılı bir politika gerek, dahili araçlar için bile. Mikro-frontend'ler kütüphaneleri tekrar edebilir ve ek ağ istekleri getirebilir. Bir performans bütçesi belirleyin (ilk yükleme süresi, bundle boyutu) ve desteklenen tarayıcı listesini tanımlayıp CI'da bunları zorunlu kılın.

Ortamlar da daha karmaşık hale gelir. Dev, staging ve prod'un nasıl çalışacağını kararlaştırın: tüm dilimler staging'de birlikte mi hareket edecek yoksa bağımsız test edilebilecek mi? Bir geliştiricinin bir formu test etmek için dört dilimi yerel çalıştırması gerekiyorsa, "bağımsız takımlar" vaadi bozulur.

AppMaster ile yönetici portalı kuruyorsanız, bazı operasyonel yüklerden kaçınabilirsiniz çünkü dağıtımlar tek bir yeniden oluşturulan uygulama olarak yönetilebilir. Gerçekten bağımsız frontend sürümleri gerekiyorsa, karmaşıklığı baştan planlayın.

Adım adım: mikro-frontend'leri güvenle deneme

Mikro-frontend'leri değerlendirmek kontrollü bir deney olarak en kolay yoldur, tam bir yeniden yazım değil. Hangi şeylerin iyileştiğini (takım bağımsızlığı) ve hangi şeylerin kötüleştiğini (daha fazla hareketli parça) öğrenin, sonra karar verin.

1) Düşük bağlı pilot ile başlayın

Her iş akışının ortasında olmayan bir alan seçin. Raporlar genellikle iyi bir adaydır: veri okur, sınırları daha nettir ve öğrenirken küçük farklılıklara tolerans gösterebilir.

Başarıyı önceden tanımlayın. Örneğin Reports ekibi tam portal release'ını koordine etmeden deploy edebilmeli ve kullanıcılar daha yavaş yükleme veya kırık navigasyon görmemeli.

2) En küçük bölünmeyi kurun

Bir host shell ve tam olarak bir mikro-frontend kurun.

• Shell giriş, üst navigasyon, temel layout ve global routing'e sahip.
• Pilot dilim sayfaları uçtan uca yönetir.
• İlk deploydan önce paylaşılan API'lerin ve hata yönetiminin sahibini kararlaştırın.
• Sınırı kilitleyin: hangi veriler çizgiyi geçecek ve hangi biçimde.

3) Ölçeklemeden önce tasarım tabanında anlaşın

İkinci bir dilim eklemeden önce temel konularda (boşluk, tipografi, form kontrolleri, tablo desenleri ve hata durumları) uzlaşın. Eğer portalda üç farklı Kaydet düğmesi varsa, kullanıcılar mimariden değil üründen şikayet eder.

4) Gerçek soruları cevaplayan izleme ekleyin

Pilot için hata oranı, yükleme süresi (ilk sayfa ve navigasyon) ve sürüm sıklığını takip edin. Eğer sürümler hızlanıyor ama hatalar artıyor veya performans bozuluyorsa bunu erken görürsünüz ve yön değiştirmek ucuzken müdahale edebilirsiniz.

Yaygın hatalar ve tuzaklar

Mikro-frontend'ler fikirden çok erken kararların maliyeti yüzünden başarısız olur. İlk hafta zararsız görünen seçimler ay altıda pahalı olur.

Klasik hata UI parçalarına göre bölmek yerine iş domainine göre bölmemektir. Bir ekip "tabloların" diğer ekip "filtrelerin" sahibi olursa, her gerçek özellik sınırları aşar. Sürekli koordinasyon, tekrarlayan mantık ve uzun inceleme döngüleri ortaya çıkar. Domain ayrımları (Kullanıcılar, Faturalama, Envanter, Destek, Raporlar) genelde daha güvencelidir.

İzinler başka bir sessiz tuzaktır. Yönetici portalları erişim kurallarına bağlıdır ve mikro-frontend'ler kontrollerin farklılaşmasına yol açabilir. Bir ekran bir butonu saklarken, başka bir ekran API çağrısını engeller, üçüncüsü ikisini de unutur. Sonuç kafa karıştırıcı davranış ya da güvenlik hatasıdır.

Aşağıdaki desenler acıyı güçlü bir şekilde öngörür:

• Tasarım sistemi isteğe bağlı olduğunda takımlar kendi UI desenlerini icat eder
• İzin kontrolleri dilimler arasında değişir, tek bir doğruluk kaynağı yok
• Paylaşılan yardımcılar herkesin düzenlediği bir karışık kutu haline gelir, versiyon çatışmaları çıkar
• Yerel geliştirme yavaşlar çünkü bir değişikliği test etmek için birçok uygulama çalıştırmak gerekir
• Takımlar bileşenlere değil sonuçlara sahip olur, bu yüzden uçtan uca akışların sahibi yoktur

Yerel geliştirme acısı en uzun süre ihmal edilen konudur. Sonra her özellik eşleşen versiyonlar gerektirir ve hangi dilimin sayfayı bozduğunu tahmin etmek gerekir.

Hızlı karar kontrol listesi

Taahhüt etmeden önce bir içgüdü testi olarak kullanın. İki veya daha fazlasına "hayır" cevabı verirseniz, iyi modüler sınırlarla tek bir frontend genelde daha güvenlidir.

• Bağımsız sürümler: En az iki ekip her değişikliği koordine etmeden gönderebilir mi?
• Paylaşılan UI kuralları: Herkes sürekli tartışma veya fork olmadan tek bir tasarım sistemini takip edebilir mi?
• Temel sahiplik: Navigasyon, kimlik doğrulama, roller ve izinler için net bir sahip var mı?
• Operasyonel hazırlık: Birden fazla build, deploy ve rollback'i her release'ı toplantıya çevirmeden yönetebilir misiniz?
• Çıkış planı: Karmaşıklık artarsa geri birleşme ya da dilim sayısını azaltma yolu net mi?

Çoğu cevap “evet” ise mikro-frontend'ler iyi bir uyum olabilir, özellikle domain alanları nadiren çakışıyorsa ve takımlar gerçekten farklı hızlarda hareket ediyorsa.

Eğer “hayır” cevapları tasarım sistemi ve paylaşılan temeller etrafında yoğunlaşıyorsa durun. Yönetici portalları tutarlı tablolar, filtreler, formlar ve izin kontrollerine dayanır. Bunlar sürüklenirse kullanıcılar hemen hisseder.

Pratik bir geri dönüş, tek bir uygulamayı tutmak ve sınırları yapı, feature flag'ler ve sahiplik kurallarıyla zorlamaktır. Ya da hızlı gönderme hedefi varsa ve çok sayıda ayrı frontend çalıştırmak istemiyorsanız, AppMaster gibi bir no-code yaklaşım modüler bir yönetici portalı inşa etmenize yardımcı olabilir; auth ve tutarlı UI desenleri tek yerde tutulur.

Örnek senaryo: dahili bir yönetici portalını domaine göre bölmek

Orta ölçekli bir şirket Sales Ops, Destek ve Finans tarafından kullanılan tek bir dahili yönetici portalı çalıştırır. Başlangıçta tek bir frontend repo, bir release pipeline ve paylaşılan sayfalar vardı. 10-15 kişiyle basit görünüyordu.

Sonra her ekip büyüdü. Sales Ops lead yönlendirme kurallarına ve panellere hızlı değişiklikler istedi. Destek yeni vaka alanları ve eskalasyon araçları istedi. Finans bekleyemeyeceği fatura iş akışları ve onaylar istedi.

Tek repo içinde bozulan sadece kod değildi. Koordinasyon bozuldu. Her değişiklik paylaşılan navigasyonu, paylaşılan tabloları, paylaşılan formları ve paylaşılan izinleri etkiliyordu. Küçük düzenlemeler uzun inceleme dizilerine, ay sonu öncesi release donmalarına ve diğer ekipleri bozan sürpriz UI değişikliklerine yol açtı.

Pragmatik bir bölünme önce ince bir kabuk tutup iki domain uygulaması çıkarmaktır:

• Shell: giriş, global navigasyon, kullanıcı bağlamı, paylaşılan UI bileşenleri
• Finans: faturalar, ödemeler, onaylar, denetim görünümleri
• Destek: ticket'lar, makrolar, eskalasyonlar, müşteri zaman çizelgesi

Sales Ops geçici olarak shell içinde kalır çünkü sayfaları birçok paylaşılan widget'ı yeniden kullanır ve sık değişir. Amaç riskleri azaltıp bölünmenin kendini kanıtlamasını sağlamaktır.

Altı hafta sonra başarı ölçülebilir olmalı: Finans haftalık gönderim yapabiliyor, hotspot düzeltmeleri daha hızlı, PR inceleme süresi azaldı, UI tutarlılığı paylaşılan bileşenlerin sahipliği sayesinde iyileşti ve bir domain hatası tüm portalı düşürmez oldu.

AppMaster ile yönetici portalı inşa ediyorsanız aynı fikri her domaini kendi uygulamanız olarak ele alıp tek bir paylaşılan UI desenleri ve roller setini koruyarak uygulayabilirsiniz. Bu bağımsızlığı gerçek tutarken portalın üç farklı ürün gibi hissettirmesini engeller.

Sonraki adımlar: bir yol seçin ve riski azaltın

Portalınız bugün çalışıyorsa, genelde en güvenli sonraki adım yeniden yazım değildir. Mevcut düzeni değiştirilebilmesi daha kolay hale getirmektir.

Tek frontend ile devam ederseniz bile gelecekteki acıyı azaltmak için şu adımları atabilirsiniz: kodu domainlere göre gruplayın (teknik katmanlara göre değil), her domain için bir sahip atayın ve yayın disiplini üzerinde anlaşın (ne hazır sayılır, nasıl rollback yapılır ve sürpriz kırıcı değişikliklerden nasıl kaçınılır).

Mikro-frontend'e doğru hareket ediyorsanız bir küçük dilimle başlayın. Az bağımlılığı olan bir pilot domain seçin (denetim kayıtları veya fatura ayarları gibi) ve bağımlı olduğu sözleşmeleri yazın: paylaşılan UI bileşenleri, API şekilleri ve analytics event'leri. Mikro-frontend'leri en çok acıtan şey paylaşılan tasarım sistemini atlamak ve aynı kontrolleri beş farklı şekilde yeniden inşa etmektir.

Eğer gerçek hedef sadece dahili aracı hızlı göndermekse, mimari çalışmalarını bir no-code platforma karşı değerlendirmek mantıklı olabilir. AppMaster (appmaster.io) bunun bir örneğidir: üretime hazır backend'ler, web uygulamaları ve yerel mobil uygulamalar üretebilir, kimlik doğrulama, UI desenleri ve iş mantığını tek bir yerde tutabilir.

Bu hafta yapılmaya değer eylemler:

• Portalınızı 5-10 iş domainine ayırın.
• Bağımlılıkları az bir pilot domain seçin.
• Sahiplik kurallarını yazın (onaylar, paylaşılan UI sahipliği, olay yönetimi).
• Standartlaştırılması gerekenleri listeleyin (token'lar, tablolar, form desenleri, izin kontrolleri).
• Bir şey inşa etmeden önce nasıl dağıtacağınızı ve rollback yapacağınızı kararlaştırın.

İki hafta içinde bir ölçülebilir kazanım hedefleyin: daha az release çakışması, bir domain'de daha hızlı değişiklik yapabilme veya daha az UI tutarsızlığı gibi.