Mikro hizmet odaklı uygulama tasarlama

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

PDF'i indirin

Bu bölümde, varsayımsal bir sunucu tarafı kurumsal uygulama geliştirmeye odaklanmaktadır.

Uygulama belirtimleri

Varsayımsal uygulama, iş mantığını yürüterek, veritabanlarına erişerek ve ardından HTML, JSON veya XML yanıtları döndürerek istekleri işler. Uygulamanın Tek Sayfalı Uygulamalar (SPA) çalıştıran masaüstü tarayıcıları, geleneksel web uygulamaları, mobil web uygulamaları ve yerel mobil uygulamalar gibi çeşitli istemcileri desteklemesi gerektiğini söyleyeceğiz. Uygulama, üçüncü tarafların tüketmesi için bir API de kullanıma sunar. Ayrıca mikro hizmetlerini veya dış uygulamalarını zaman uyumsuz olarak tümleştirebilmelidir, böylece yaklaşım kısmi hatalarda mikro hizmetlerin dayanıklılığına yardımcı olur.

Uygulama şu bileşen türlerinden oluşur:

• Sunu bileşenleri. Bu bileşenler kullanıcı arabirimini işlemek ve uzak hizmetleri tüketmekle sorumludur.

• Etki alanı veya iş mantığı. Bu bileşen, uygulamanın etki alanı mantığıdır.

• Veritabanı erişim mantığı. Bu bileşen, veritabanlarına (SQL veya NoSQL) erişmekle sorumlu veri erişim bileşenlerinden oluşur.

• Uygulama tümleştirme mantığı. Bu bileşen, ileti aracılarını temel alan bir mesajlaşma kanalı içerir.

Uygulama yüksek ölçeklenebilirlik gerektirirken, dikey alt sistemlerinin ölçeğinin otonom olarak genişletilmesine izin verir, çünkü bazı alt sistemler diğerlerinden daha fazla ölçeklenebilirlik gerektirir.

Uygulamanın birden çok altyapı ortamına (birden çok genel bulut ve şirket içi) dağıtılabilmesi ve ideal olarak platformlar arası olması ve Linux'tan Windows'a kolayca taşınabilmesi (veya tam tersi) olması gerekir.

Geliştirme ekibi bağlamı

Ayrıca uygulamanın geliştirme süreci hakkında da aşağıdakileri varsayıyoruz:

• Uygulamanın farklı iş alanlarına odaklanan birden çok geliştirme ekibiniz var.

• Yeni ekip üyelerinin hızla üretken olması ve uygulamanın anlaşılması ve değiştirilmesi kolay olmalıdır.

• Uygulamanın uzun vadeli bir evrimi ve sürekli değişen iş kuralları olacaktır.

• Uzun süreli bakım konusunda iyi bir gereksinim duyarsınız; bu da gelecekte yeni değişiklikler uygularken çevikliğe sahip olmak ve diğer alt sistemleri en az etkileyerek birden çok alt sistemi güncelleştirebilmek anlamına gelir.

• Uygulamanın sürekli tümleştirmesini ve sürekli dağıtımını uygulamak istiyorsunuz.

• Uygulamayı geliştirirken gelişmekte olan teknolojilerden (çerçeveler, programlama dilleri vb.) yararlanmak istiyorsunuz. Yeni teknolojilere geçerken uygulamanın tam geçişini yapmak istemezsiniz, çünkü bu yüksek maliyetlere neden olur ve uygulamanın öngörülebilirliğini ve kararlılığını etkiler.

Mimari seçme

Uygulama dağıtım mimarisi ne olmalıdır? Uygulamanın belirtimleri ve geliştirme bağlamı, mikro hizmetin kapsayıcı olduğu mikro hizmetler ve kapsayıcılar gibi otonom alt sistemlere ayırarak uygulamanın mimarisini oluşturmanızı kesinlikle önerir.

Bu yaklaşımda, her hizmet (kapsayıcı) bir dizi uyumlu ve dar ilişkili işlev uygular. Örneğin, bir uygulama katalog hizmeti, sipariş hizmeti, sepet hizmeti, kullanıcı profili hizmeti gibi hizmetlerden oluşabilir.

Mikro hizmetler, özellikle tümleştirme olaylarıyla güncelleştirmeleri dağıtırken mümkün olduğunda HTTP (REST) gibi protokolleri kullanarak ancak zaman uyumsuz olarak (örneğin AMQP kullanarak) iletişim kurar.

Mikro hizmetler birbirinden bağımsız olarak kapsayıcı olarak geliştirilir ve dağıtılır. Bu yaklaşım, bir geliştirme ekibinin diğer alt sistemleri etkilemeden belirli bir mikro hizmeti geliştirebileceği ve dağıtabileceği anlamına gelir.

Her mikro hizmetin kendi veritabanı vardır ve diğer mikro hizmetlerden tamamen ayrıştırılabilir. Gerektiğinde, Komut ve Sorgu Sorumluluğu Ayrımı (CQRS) bölümünde ele alınan uygulama düzeyi tümleştirme olayları (mantıksal olay veri yolu aracılığıyla) kullanılarak farklı mikro hizmetlerden veritabanları arasında tutarlılık elde edilir. Bu nedenle, iş kısıtlamalarının birden çok mikro hizmet ve ilgili veritabanı arasındaki nihai tutarlılığı benimsemesi gerekir.

eShopOnContainers: Kapsayıcılar kullanılarak dağıtılan .NET ve mikro hizmetler için başvuru uygulaması

Bilmediğiniz varsayımsal bir iş etki alanını düşünmek yerine mimariye ve teknolojilere odaklanabilmeniz için, iyi bilinen bir iş alanı seçtik; yani bir ürün kataloğu sunan, müşterilerden sipariş alan, envanteri doğrulayan ve diğer iş işlevlerini gerçekleştiren basitleştirilmiş bir e-ticaret (e-shop) uygulaması. Bu kapsayıcı tabanlı uygulama kaynak kodu, eShopOnContainers GitHub deposunda kullanılabilir.

Uygulama, iç mikro hizmetlere birleştirilmiş giriş noktaları olarak çeşitli API Ağ Geçitleri ile gerekli tüm sunucu tarafı işlemleri için arka uç mikro hizmetleri ve kapsayıcıların yanı sıra çeşitli mağaza kullanıcı arabirimi ön uçları (web uygulaması ve yerel mobil uygulama) dahil olmak üzere birden çok alt sistemden oluşur. Şekil 6-1'de başvuru uygulamasının mimarisi gösterilmektedir.

Şekil 6-1. Geliştirme ortamı için eShopOnContainers başvuru uygulaması mimarisi

Yukarıdaki diyagramda Mobil ve SPA istemcilerinin tek API ağ geçidi uç noktalarıyla iletişim kurarak mikro hizmetlerle iletişim kurduğunu gösterilmektedir. Geleneksel web istemcileri, API ağ geçidi aracılığıyla mikro hizmetlerle iletişim kuran MVC mikro hizmetiyle iletişim kurar.

Barındırma ortamı. Şekil 6-1'de, tek bir Docker konağı içinde dağıtılmış birkaç kapsayıcı görürsünüz. Docker-compose up komutuyla tek bir Docker konağına dağıtım yaparken bu durum söz konusu olabilir. Ancak, bir düzenleyici veya kapsayıcı kümesi kullanıyorsanız, her kapsayıcı farklı bir konakta (düğüm) çalışıyor olabilir ve mimari bölümünde daha önce açıkladığımız gibi herhangi bir düğüm herhangi bir sayıda kapsayıcı çalıştırıyor olabilir.

İletişim mimarisi. eShopOnContainers uygulaması, işlevsel eylemin türüne bağlı olarak iki iletişim türü kullanır (sorgular ve güncelleştirmeler ve işlemler):

• API Gateway'ler aracılığıyla http istemciden mikro hizmete iletişim. Bu yaklaşım, istemci uygulamalarından güncelleştirme veya işlem komutlarını kabul ederken ve sorgular için kullanılır. API Gateway'leri kullanma yaklaşımı sonraki bölümlerde ayrıntılı olarak açıklanmıştır.

• Zaman uyumsuz olay tabanlı iletişim. Bu iletişim, güncelleştirmeleri mikro hizmetlere yaymak veya dış uygulamalarla tümleştirmek için bir olay veri yolu aracılığıyla gerçekleşir. Olay veri yolu RabbitMQ gibi herhangi bir mesajlaşma aracısı altyapı teknolojisiyle veya Azure Service Bus, NServiceBus, MassTransit veya Brighter gibi üst düzey (soyutlama düzeyi) hizmet veri yolları kullanılarak uygulanabilir.

Uygulama, kapsayıcılar biçiminde bir mikro hizmet kümesi olarak dağıtılır. İstemci uygulamaları, API Gateway'ler tarafından yayımlanan genel URL'ler aracılığıyla kapsayıcı olarak çalışan mikro hizmetlerle iletişim kurabilir.

Mikro hizmet başına veri hakimiyeti

Tüm SQL Server veritabanları tek bir kapsayıcı olarak dağıtılsa da, örnek uygulamada her mikro hizmetin kendi veritabanı veya veri kaynağı vardır. Bu tasarım kararı yalnızca geliştiricinin kodu GitHub'dan alması, kopyalaması ve Visual Studio veya Visual Studio Code'da açmasını kolaylaştırmak için alınmıştı. Alternatif olarak, .NET CLI ve Docker CLI kullanarak özel Docker görüntülerini derlemeyi ve ardından bunları bir Docker geliştirme ortamında dağıtıp çalıştırmayı kolaylaştırır. Her iki durumda da, veri kaynakları için kapsayıcıları kullanmak, geliştiricilerin bir dış veritabanı veya altyapıya (bulut veya şirket içi) yönelik sabit bağımlılıkları olan başka bir veri kaynağı sağlamak zorunda kalmadan birkaç dakika içinde derlenip dağıtılmasına olanak tanır.

Gerçek bir üretim ortamında, yüksek kullanılabilirlik ve ölçeklenebilirlik için veritabanları buluttaki veya şirket içindeki veritabanı sunucularını temel almalıdır ancak kapsayıcılarda olmamalıdır.

Bu nedenle, mikro hizmetler (ve hatta bu uygulamadaki veritabanları için) için dağıtım birimleri Docker kapsayıcılarıdır ve başvuru uygulaması mikro hizmet ilkelerini benimseyen çok kapsayıcılı bir uygulamadır.

Ek kaynaklar

• eShopOnContainers GitHub deposu. Başvuru uygulaması için kaynak kodu
  https://aka.ms/eShopOnContainers/

Mikro hizmet tabanlı çözümün avantajları

Bunun gibi mikro hizmet tabanlı bir çözümün birçok avantajı vardır:

Her mikro hizmet nispeten küçüktür; yönetilmesi ve gelişmesi kolaydır. Özellikle:

• Bir geliştiricinin iyi bir üretkenliği anlaması ve hızlı bir şekilde kullanmaya başlaması kolaydır.

• Kapsayıcılar hızlı bir şekilde başlatılır ve bu sayede geliştiriciler daha üretken hale getirilir.

• Visual Studio gibi bir IDE daha küçük projeleri hızla yükleyebilir ve geliştiricileri üretken hale getirir.

• Her mikro hizmet, diğer mikro hizmetlerden bağımsız olarak tasarlanabilir, geliştirilebilir ve dağıtılabilir ve bu da sık sık mikro hizmetlerin yeni sürümlerini dağıtmak daha kolay olduğundan çeviklik sağlar.

Uygulamanın tek tek alanlarının ölçeğini genişletmek mümkündür. Örneğin, katalog hizmetinin veya sepet hizmetinin ölçeğinin genişletilmesi gerekebilir, ancak sıralama işleminin ölçeği genişletilmeyebilir. Mikro hizmetler altyapısı, ölçeği genişletirken kullanılan kaynaklar açısından monolitik mimariden çok daha verimli olacaktır.

Geliştirme çalışmalarını birden çok ekip arasında bölebilirsiniz. Her hizmet tek bir geliştirme ekibine ait olabilir. Her ekip, hizmetlerini diğer ekiplerden bağımsız olarak yönetebilir, geliştirebilir, dağıtabilir ve ölçeklendirebilir.

Sorunlar daha yalıtılmış durumdadır. Bir hizmette sorun varsa, başlangıçta yalnızca bu hizmet etkilenir (mikro hizmetler arasındaki doğrudan bağımlılıklarla yanlış tasarım kullanılması dışında) ve diğer hizmetler istekleri işlemeye devam edebilir. Buna karşılık, monolitik dağıtım mimarisindeki bir arızalı bileşen, özellikle bellek sızıntısı gibi kaynaklar içerdiğinde sistemin tamamını çökertir. Ayrıca, bir mikro hizmetteki bir sorun çözüldüğünde, uygulamanın geri kalanını etkilemeden yalnızca etkilenen mikro hizmeti dağıtabilirsiniz.

En son teknolojileri kullanabilirsiniz. Hizmetleri bağımsız olarak geliştirmeye başlayıp yan yana çalıştırabildiğiniz için (kapsayıcılar ve .NET sayesinde), uygulamanın tamamı için eski bir yığına veya çerçeveye takılı kalmak yerine en son teknolojileri ve çerçeveleri deneyimli bir şekilde kullanmaya başlayabilirsiniz.

Mikro hizmet tabanlı çözümün dezavantajları

Bunun gibi mikro hizmet tabanlı bir çözümün bazı dezavantajları da vardır:

Dağıtılmış uygulama. Uygulamayı dağıtmak, hizmetleri tasarlarken ve oluştururken geliştiriciler için karmaşıklık ekler. Örneğin, geliştiricilerin HTTP veya AMQP gibi protokolleri kullanarak hizmetler arası iletişim uygulaması gerekir ve bu da test ve özel durum işleme için karmaşıklık ekler. Ayrıca sisteme gecikme süresi ekler.

Dağıtım karmaşıklığı. Onlarca mikro hizmet türüne sahip olan ve yüksek ölçeklenebilirlik gerektiren bir uygulama (hizmet başına çok sayıda örnek oluşturabilmesi ve bu hizmetleri birçok konakta dengeleyebilmesi gerekir), BT işlemleri ve yönetimi için yüksek düzeyde dağıtım karmaşıklığı anlamına gelir. Mikro hizmet odaklı bir altyapı (düzenleyici ve zamanlayıcı gibi) kullanmıyorsanız, bu ek karmaşıklık iş uygulamasının kendisinden çok daha fazla geliştirme çalışması gerektirebilir.

Atomik işlemler. Birden çok mikro hizmet arasındaki atomik işlemler genellikle mümkün değildir. İş gereksinimlerinin birden çok mikro hizmet arasındaki nihai tutarlılığı benimsemesi gerekir. Daha fazla bilgi için bkz . Bir kez etkili ileti işlemenin zorlukları.

Artan genel kaynak gereksinimleri (tüm sunucular veya konaklar için toplam bellek, sürücü ve ağ kaynakları). Çoğu durumda, monolitik bir uygulamayı mikro hizmetler yaklaşımıyla değiştirdiğinizde, yeni mikro hizmet tabanlı uygulamanın ihtiyaç duyduğu ilk genel kaynak miktarı özgün monolitik uygulamanın altyapı gereksinimlerine göre daha fazla olacaktır. Bu yaklaşımın nedeni, daha yüksek ayrıntı düzeyi ve dağıtılmış hizmetlerin daha fazla genel kaynak gerektirmesidir. Ancak, genel olarak kaynakların düşük maliyeti ve monolitik uygulamalar geliştirilirken uygulamanın belirli alanlarının ölçeğini uzun vadeli maliyetlerle karşılaştırıldığında genişletebilmenin avantajı göz önünde bulundurulduğunda, kaynakların artan kullanımı genellikle büyük, uzun vadeli uygulamalar için iyi bir dengedir.

Doğrudan istemciden mikro hizmete iletişimle ilgili sorunlar. Uygulama büyük olduğunda, onlarca mikro hizmet olduğunda, uygulamanın doğrudan istemciden mikro hizmete iletişim gerektirmesi durumunda zorluklar ve sınırlamalar vardır. Sorunlardan biri, istemcinin gereksinimleriyle mikro hizmetlerin her biri tarafından kullanıma sunulan API'ler arasında olası bir uyuşmazlıktır. Bazı durumlarda, istemci uygulamasının kullanıcı arabirimini oluşturmak için birçok ayrı istekte bulunmaları gerekebilir. Bu istekler İnternet üzerinden verimsiz olabilir ve mobil ağ üzerinden pratik olmayabilir. Bu nedenle, istemci uygulamasından arka uç sistemine yönelik istekler en aza indirilmelidir.

Doğrudan istemciden mikro hizmete iletişimle ilgili bir diğer sorun da bazı mikro hizmetlerin Web kullanımı kolay olmayan protokoller kullanıyor olmasıdır. Bir hizmet ikili protokol kullanırken, başka bir hizmet AMQP mesajlaşması kullanabilir. Bu protokoller güvenlik duvarı kullanımına uygun değildir ve en iyi şekilde dahili olarak kullanılır. Genellikle, bir uygulama güvenlik duvarı dışında iletişim için HTTP ve WebSockets gibi protokoller kullanmalıdır.

Bu doğrudan istemciden hizmete yaklaşımın bir diğer dezavantajı da, bu mikro hizmetler için sözleşmelerin yeniden düzenlenmesini zorlaştırıyor olmasıdır. Zaman içinde geliştiriciler sistemin hizmetlere nasıl bölümlendiğini değiştirmek isteyebilir. Örneğin, iki hizmeti birleştirir veya bir hizmeti iki veya daha fazla hizmete bölebilir. Ancak, istemciler hizmetlerle doğrudan iletişim kurarsa, bu tür bir yeniden düzenleme yapmak istemci uygulamalarıyla uyumluluğu bozabilir.

Mimari bölümünde belirtildiği gibi, mikro hizmetlere dayalı karmaşık bir uygulama tasarlayıp oluştururken, daha basit doğrudan istemciden mikro hizmete iletişim yaklaşımı yerine birden çok ayrıntılı API Ağ Geçidi kullanmayı düşünebilirsiniz.

Mikro hizmetleri bölümleme. Son olarak, mikro hizmet mimariniz için hangi yaklaşımı benimsediğiniz fark etmez, bir diğer zorluk da bir uçtan uca uygulamanın birden çok mikro hizmete nasıl bölümlendiğine karar vermektir. Kılavuzun mimari bölümünde belirtildiği gibi, kullanabileceğiniz çeşitli teknikler ve yaklaşımlar vardır. Temel olarak, uygulamanın diğer alanlardan ayrılmış ve az sayıda sabit bağımlılığı olan alanlarını belirlemeniz gerekir. Çoğu durumda, bu yaklaşım kullanım örneğine göre bölümleme hizmetleriyle uyumlu hale gelir. Örneğin, e-mağaza uygulamamızda, sipariş süreciyle ilgili tüm iş mantığından sorumlu olan bir sipariş hizmetimiz var. Ayrıca katalog hizmetimiz ve diğer özellikleri uygulayan sepet hizmetimiz de vardır. İdeal olarak, her hizmetin yalnızca küçük bir sorumluluk kümesi olmalıdır. Bu yaklaşım, sınıflara uygulanan tek sorumluluk ilkesine (SRP) benzerdir ve bir sınıfın değiştirilmesi için yalnızca bir nedeni olması gerektiğini belirtir. Ancak bu durumda, mikro hizmetlerle ilgili olduğundan kapsam tek bir sınıftan daha büyük olacaktır. En önemlisi, bir mikro hizmetin kendi veri kaynaklarının sorumluluğu da dahil olmak üzere uçtan uca otonom olması gerekir.

Dış mimari ile iç mimari ve tasarım desenleri karşılaştırması

Dış mimari, bu kılavuzun mimari bölümünde açıklanan ilkeleri izleyerek birden çok hizmet tarafından oluşturulan mikro hizmet mimarisidir. Ancak, her mikro hizmetin doğasına bağlı olarak ve seçtiğiniz üst düzey mikro hizmet mimarisinden bağımsız olarak, farklı mikro hizmetler için her biri farklı desenleri temel alan farklı iç mimarilere sahip olmanız yaygın ve bazen önerilir. Mikro hizmetler farklı teknolojiler ve programlama dilleri bile kullanabilir. Şekil 6-2'de bu çeşitlilik gösterilmektedir.

Şekil 6-2. Dış ve iç mimari ve tasarım karşılaştırması

Örneğin, eShopOnContainers örneğimizde katalog, sepet ve kullanıcı profili mikro hizmetleri basittir (temel olarak CRUD alt sistemleri). Bu nedenle, iç mimarileri ve tasarımı basittir. Ancak, daha karmaşık olan ve etki alanı karmaşıklığı yüksek olan sürekli değişen iş kurallarını temsil eden sipariş mikro hizmeti gibi başka mikro hizmetleriniz de olabilir. Böyle durumlarda, eShopOnContainers sipariş mikro hizmetinde yaptığımız gibi, etki alanı odaklı tasarım (DDD) yaklaşımlarıyla tanımlananlar gibi belirli bir mikro hizmet içinde daha gelişmiş desenler uygulamak isteyebilirsiniz. (Daha sonra mikro hizmet sipariş eden eShopOnContainers uygulamasını açıklayan bölümde bu DDD desenlerini gözden geçireceğiz.)

Mikro hizmet başına farklı bir teknolojinin başka bir nedeni de her mikro hizmetin doğası olabilir. Örneğin, C# gibi daha nesne odaklı bir programlama dili yerine, yapay zeka ve makine öğrenmesi etki alanlarını hedef alıyorsanız F# gibi işlevsel bir programlama dili veya hatta R gibi bir dil kullanmak daha iyi olabilir.

Alt çizgi, her mikro hizmetin farklı tasarım desenlerine göre farklı bir iç mimariye sahip olabileceğidir. Tüm mikro hizmetler gelişmiş DDD desenleri kullanılarak uygulanmamalıdır, çünkü bu aşırı mühendisliktir. Benzer şekilde, sürekli değişen iş mantığına sahip karmaşık mikro hizmetler CRUD bileşenleri olarak uygulanmamalıdır veya düşük kaliteli kodla sonuçlanabilirsiniz.

Yeni dünya: birden çok mimari desen ve çok yönlü mikro hizmetler

Yazılım mimarları ve geliştiriciler tarafından kullanılan birçok mimari desen vardır. Aşağıda birkaç (mimari stillerini ve mimari desenlerini karıştırma) yer alır:

• Basit CRUD, tek katmanlı, tek katmanlı.

• Geleneksel N Katmanlı.

• Etki Alanı Odaklı Tasarım N katmanlı.

• Temiz Mimari (eShopOnWeb ile kullanıldığı gibi)

• Komut ve Sorgu Sorumluluğu Ayrım ( CQRS).

• Olay Odaklı Mimari (EDA).

Ayrıca ASP.NET Core Web API'leri, NancyFx, ASP.NET Core SignalR (.NET Core 2 veya üzeri ile kullanılabilir), F#, Node.js, Python, Java, C++, GoLang ve daha fazlası gibi birçok teknoloji ve dille mikro hizmetler oluşturabilirsiniz.

Önemli nokta, belirli bir mimari deseninin veya stilinin ya da herhangi bir teknolojinin tüm durumlar için doğru olmamasıdır. Şekil 6-3'te farklı mikro hizmetlerde kullanılabilecek bazı yaklaşımlar ve teknolojiler (belirli bir sırada olmasa da) gösterilmektedir.

Şekil 6-3. Çok mimarili desenler ve poliglot mikro hizmetler dünyası

Çok mimarili desen ve çok yönlü mikro hizmetler, dilleri ve teknolojileri her mikro hizmetin ihtiyaçlarıyla karıştırıp eşleştirebileceğiniz ve hala birbirleriyle konuşmalarını sağlayabileceğiniz anlamına gelir. Şekil 6-3'te gösterildiği gibi, birçok mikro hizmetten oluşan uygulamalarda (etki alanı odaklı tasarım terminolojisindeki Sınırlanmış Bağlamlar veya yalnızca otonom mikro hizmetler olarak "alt sistemler"), her mikro hizmeti farklı bir şekilde uygulayabilirsiniz. Her biri farklı bir mimari düzenine sahip olabilir ve uygulamanın doğasına, iş gereksinimlerine ve önceliklerine bağlı olarak farklı diller ve veritabanları kullanabilir. Bazı durumlarda mikro hizmetler benzer olabilir. Ancak her alt sistemin bağlam sınırı ve gereksinimleri genellikle farklı olduğundan bu durum genellikle böyle değildir.

Örneğin basit bir CRUD bakım uygulaması için DDD desenleri tasarlamak ve uygulamak mantıklı olmayabilir. Ancak temel etki alanınız veya temel işletmeniz için, sürekli değişen iş kurallarıyla iş karmaşıklığını ele almak için daha gelişmiş desenler uygulamanız gerekebilir.

Özellikle birden çok alt sistem tarafından oluşturulan büyük uygulamalarla uğraşırken, tek bir mimari deseni temelinde tek bir üst düzey mimari uygulamamalısınız. Örneğin, CQRS tüm uygulama için en üst düzey mimari olarak uygulanmamalıdır, ancak belirli bir hizmet kümesi için yararlı olabilir.

Verilen her durum için gümüş madde işareti veya doğru mimari deseni yoktur. "Tümünü yönetmek için tek bir mimari desenine" sahip olamazsınız. Her mikro hizmetin önceliklerine bağlı olarak, aşağıdaki bölümlerde açıklandığı gibi her biri için farklı bir yaklaşım seçmelisiniz.

Geriİleri