DDD ve CQRS

Uygulamalarımızda reuse edebilecğimiz common patternleri  bulmamızı sağlayan DDD tekniklerine genel bir bakış yapacağız.

Apply simplified CQRS and DDD patterns in a microservice

• CQRS, dataları read ve write için ayrı  modellere ayıran bir architectural patterndir.
• Ana fikir, bir sistemin operasyonlarını keskin bir şekilde ayrılmış iki kategoriye ayırabilmenizdir:

Queries : Sistemin durumunu (state) değiştirmez, Geriye bir  result return eder ve side effect yoktur.(Get Operation)

Commands: Sistemin durumunu değiştirir.(Add,Update,Delete)

CQRS, Query ve Command operasyonları için ayrı birer logical  model oluşturulması gerektiğini söyler. Burada query ve commandlar için ayrı birer database olması şart değildir. Fakat modeller farklı olmalıdır. 

Command ve Queryler için ayrı birer logical model oluşturmanın en büyük faydası Command işlemleri için uygulanan DDD kısıtlamalarının Queryleri etkilemeyecek olmasıdır. 

Queryler, Idempotenttir. Yani kaç kere aynı query çalıştırırsak çalıştıralım sistemin durumu değişmeyecektir ve  geriye sadece veri tabanından data return edilecektir.

Öte yandan Commandlar  transaction ve data update işlemlerini tetikleyerek sistemin durumu(state) değiştirir. Commandlarla, karmaşıklık ve sürekli değişen bussines rulelarla  uğraşırken dikkatli olmanız gerekir. Daha iyi modellenmiş bir sisteme sahip olmak için DDD tekniklerini uygulayacağımız yer burasıdır.

Domain Driven Desing

DDD, problemleri domain olarak nitelendirir. Birbirinden bağımsız her bir problem Bounded Context olarak tanımlanır ve problem üzerine konuşmak için ortak bir dil kullanılır.(Her Bounded Context bir micro servise karşılık gelir.). Uygulama implementasyonunda Entity Domain With Rich Entity, ValueObjects, Aggregates ve AggregateRoot(entity root) gibi kavramlar kullanılır. 

DDD yaklaşımları, sadece önemli bussines rulelara sahip complex mikro servisler oluşturmanız gerektiğinde kullanılmalıdır. CRUD servisleri gibi basit uygulamalar için uygulanmamalıdır.

Keep the microservice context boundaries small

Bounded Contextleri belirlerken aşağıdaki durumlar dikkate alınmalıdır. 

• İki mikro servisin birbiriyle çok fazla işbirliği yapması gerekiyorsa, muhtemelen aynı mikro servis olmalıdırlar.
• Micro servisler özerk(autonomy) olmalıdır. Bir mikro servisin , bir talebe doğrudan hizmet vermesi için başka bir servise bağlı olması gerekiyorsa, gerçekten özerk(autonomy) değildir.

Layers in DDD microservices

Önemli bussines  ve teknik karmaşıklığa sahip çoğu kurumsal uygulama, birden çok katmanla tasarlanır.  Farklı katmanlar geliştiricilerin kod karmaşıklığını yönetmesini kolaylaştırır. 

AggregateRootlar tarafından kontrol edilen always-valid entitiylere sahip olmanız gerekir. Bu  yüzden  entityler, client viewlara  bağlı olmamalıdır, çünkü UI  düzeyinde bazı veriler validate edilmemiş olabilir. ViewModel, yalnızca Presentation Layer gereksinimlerine yönelik bir data modelidir. Domain model entityleri  doğrudan ViewModel'e ait değildir. Bunun yerine, ViewModels ve Domain Model Entityleri  arasında translate/map yapmamız gerekir.

Yukarıda tanımlanmış layerlar arasındaki bağımlılıklar iyi yönetilmelidir. Domain Layer hiç bir layera bağımlı olmamalıdır. 

Bir Domain Model Entitysi, Behaviorları metodlar aracılığıyla implemente eder , Yani  "anemic" model gibi değildir. Bazen herhangi bir logici uygulamayan Entitylere sahip olabilirsiniz. 

Anemic Modelin en büyük belirtisi bu entityler içerisinde hiç bir behavior yoktur. Sadece propertylerden ibarettir. Geleneksel yöntemlerde Business Layer data modelin üzerinde yer alır ve data modeli sadece data olarak kullanır. Anemic Domain Model, yalnızca prosedürel stilde bir tasarımdır. Anemik Entity Objeleri , behaviordan(yöntemlerden) yoksun oldukları için gerçek nesne değildir. Sadece data propertyleri tutarlar ve bu nedenle nesne yönelimli tasarım değildir. Tüm behavioru servis nesnelerine (business layer) koyarak, aslında spagetti kodu veya işlem betikleri elde edersiniz ve bu nedenle bir domain modelin sağladığı avantajları kaybedersiniz.

Ne olursa olsun, Mikro Servisiniz veya Bounded Contextiniz çok basitse (bir CRUD hizmeti), yalnızca data propertylere  sahip entity objeleri biçimindeki anamic domain modeli yeterli olabilir ve daha karmaşık DDD kalıpları uygulamaya değmeyebilir. Bu durumda, CRUD için  sadece datalarla bir entity oluşturduğunuz için bunun ismi  Persistence Model olacaktır.

Bazı insanlar anemic domain modelin bir anti-kalıp olduğunu söylüyor. Bu gerçekten ne uyguladığınıza bağlıdır. Oluşturmakta olduğunuz mikro servis yeterince basitse (örneğin, bir CRUD hizmeti), anamic domaic model burada  bir anti-kalıp değildir

How you can determine where the 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗹𝗼𝗴𝗶𝗰 should reside in DDD !?

Within Domain-Driven Design, the essence of business logic is divided into two distinct layers: 𝗗𝗼𝗺𝗮𝗶𝗻 𝗟𝗼𝗴𝗶𝗰 and 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗟𝗼𝗴𝗶𝗰.

𝗗𝗼𝗺𝗮𝗶𝗻 𝗟𝗼𝗴𝗶𝗰 encapsulates the core domain rules governing the system, while 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗟𝗼𝗴𝗶𝗰 is responsible for implementing application-specific use cases.

Even though we understand the concept, putting it into practice isn't always straightforward. Figuring out which code belongs in the Application Layer and which in the Domain Layer can be tricky

asking "𝘄𝗵𝗲𝘁𝗵𝗲𝗿 𝘁𝗵𝗲 𝗹𝗼𝗴𝗶𝗰 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝗮𝗰𝗿𝗼𝘀𝘀 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝘂𝘀𝗲 𝗰𝗮𝘀𝗲𝘀" is a fundamental question to determine whether it belongs in the Domain Layer or the Application Layer in Domain-Driven Design (DDD).

Let's take an example of 𝗠𝗲𝗺𝗯𝗲𝗿𝘀𝗵𝗶𝗽 𝗥𝗲𝗴𝗶𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻.

In this scenario, every guest who registers for membership must be charged $1. However, if the member is added by certain use cases, such as the operation team, no charge is applied.

so as you can see charging $1 for membership is not necessary to be able to create a new membership. It's an application logic specific to certain use cases.

DBContext, Fluent Api EntityTypeConfiguration

 

    public class ApplicationDbContext : DbContext
    {
        public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options):base(options)
        {

        }       
        public DbSet<Gathering> Gathering { get; set; }
        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.ApplyConfigurationsFromAssembly(Assembly.GetExecutingAssembly());

            base.OnModelCreating(modelBuilder);
        }
    }

    public class GatheringConfiguration : IEntityTypeConfiguration<Gathering>
    {
        public void Configure(EntityTypeBuilder<Gathering> builder)
        {
            builder.HasKey(x => x.Id);
            
        }
    }

Infrastructure Layer

    public static class AssemblyReference
    {
        public static readonly Assembly Assembly = typeof(Assembly).Assembly;
        public static IServiceCollection AddPersistence(this IServiceCollection services, IConfiguration configuration)
        {
            services.AddDbContext<ApplicationDbContext>((sp, optionBuilder) =>
            {;
                DbContextOptionsBuilder dbContextOptionsBuilder = optionBuilder.UseSqlServer(
                    configuration.GetConnectionString("Default")
                    );
            });
            return services;
        }
    }

Program.cs

builder.Services
    .AddPersistence(builder.Configuration);

Fluent Api Reference

Filters

 

• Middleware, ASP.NET Core seviyesinde çalışır ve uygulamaya gelen her request üzerinde işlem yapabilir.
• MVC filters ise yalnızca MVC'ye gelen requestler için çalışır. (eg: ModelState or IActionResults)
• Middleware, HttpContext gibi daha düşük düzeyli soyutlamalar üzerinde çalışan daha genel bir kavramdır.Onun için uygulamaya gelem tüm requestlere uygulanmasını istiyorsak Middleware, Controller yada action bazlı olmasını istiyorsak Filters kullanmalıyız.

Örneğin, tüm  requestlerin HTTPS üzerinden yapılmasını zorunlu olmasını istersek bunun için middleware kullanmamız gerekir. Eğer bunu filters ile yaparsak http requestleri statik dosyalara kadar erişebilir.

In ASP.NET Core, middleware and filters are both used to implement cross-cutting concerns that affect multiple requests in an application. While they have some similarities, there are also some key differences between them.

Middleware is a software component that is executed between the web server and the application. It intercepts incoming HTTP requests and outgoing responses, and can perform a wide variety of tasks such as authentication, logging, and exception handling. Middleware is implemented as a chain, with each middleware component in the chain responsible for processing the request and passing it on to the next component in the chain.

Filters, on the other hand, are used to implement cross-cutting concerns that are specific to an action or a controller. Filters are executed before or after an action is executed, and can perform tasks such as authorization, validation, and caching. Filters are implemented as attributes that can be applied to actions or controllers, and can be global, controller-level, or action-level.

Here are some key differences between middleware and filters:

1. Middleware is executed for every request, while filters are executed only for the actions or controllers that they are applied to.

2. Middleware operates on the entire request and response, while filters operate on specific actions or controllers.

3. Middleware can be implemented as a pipeline, with each middleware component in the pipeline responsible for processing the request and passing it on to the next component. Filters, on the other hand, are not part of a pipeline.

4. Middleware can be used to implement a wide range of cross-cutting concerns, while filters are generally used for concerns that are specific to an action or a controller.

In summary, middleware and filters both provide ways to implement cross-cutting concerns in an ASP.NET Core application, but they have different scopes and are used for different purposes

Load Balancing, Api Gateway, Backend For Frontend ( BFF )

API Gateway , uygun mikro servise yönelik 𝗿𝗼𝘂𝘁𝗶𝗻𝗴 isteklerine odaklanırken, Load balancer, bir grup backend serverında eşit şekilde 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗻𝗴 requestlerine odaklanır.

API Gateway ve Load Balancer, gelen requestleri yönetmek ve bir sistemin performansını artırmak için bir bilgisayar ağında kullanılabilen altyapı türleridir. Ancak, farklı şekillerde çalışırlar ve farklı amaçlara hizmet ederler.

Load Balancing,

• Bilinen tek bir IP adresine gönderilen requestleri handle etmek ve trafiği birden çok backend servera dağıtmak için kullanılan bir kavramdır. Backend serverlar arasında etkili bir trafik yönlendirme algoritması kullanan load balancerlar, dinamik trafik ihtiyaçları genelinde backend layerın performansının ve resiliency korunmasını sağlar.
• Çalışan bir hizmetin kullanılabilirliğini belirlemek için health checks  kullanan load balancerlar, müşterileri requestlerini tüm unhealty downstreamden yalıtır. Yani amaç Performasn ve Availabilityi sağlamak.

Api Gateway

API Gateway, mikroservis mimarisinde tüm mikroservislerin dış dünyayla olan iletişimini yöneten merkezi bir giriş noktasıdır. API Gateway, kullanıcı taleplerini mikroservislere yönlendirir, yanıtları toplar ve tek bir yanıt olarak kullanıcılara iletir. Bu yapı, mikroservislerin dış dünyadan izole edilmesini ve sistemin daha güvenli, yönetilebilir ve performanslı çalışmasını sağlar. API Gateway, mikroservis mimarisinin temel bileşenlerinden biridir ve güvenlik, yük dengeleme, izleme, veri dönüştürme gibi pek çok işlevi üstlenebilir.

• Bir dizi micro servis için tek bir giriş noktası görevi gören bir sunucudur.(server)
• Client requestlerini alır, bunları uygun mikro servislere iletir ve  responseyi clienta döndürür.
• API Gateway  routing, authentication ve rate limit  gibi görevlerden sorumludur. Böylece micro servislerin kendi işlerine odaklanmasını sağlar ve sistemin genel performansını ve ölçeklenebilirliğini arttırır..

𝗥𝗼𝘂𝘁𝗶𝗻𝗴: API Gateway , Clientlardan requestleri alır ve bunları uygun mikro hizmete yönlendirir. Böylece clientlar çeşitli micro servisler için tek bir giriş noktası üzerinden erişim sağlar ve sistemi basitleştirilmiş olur.

𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻: API Gateway , Clientların kimliğini doğrulamak ve mikro servisler için erişim denetimi policyleri uygulamak için kullanılabilir. Böylece sadece yetkili clientlar mikro servislere erişebilmesini sağlamaya ve yetkisiz erişimi önlemeye yardımcı olur.

𝗥𝗮𝘁𝗲 𝗹𝗶𝗺𝗶𝘁𝗶𝗻𝗴: Bir API Gateway  ile mikro servislere client erişimini sınırlayabilirsiniz. Böylece sürekli request gönderme saldırılarını ve diğer kötü niyetli davranış türlerini önlemeye yardımcı olabilir.

𝗟𝗼𝗮𝗱 𝗯𝗮𝗹𝗮𝗻𝗰𝗶𝗻𝗴: API Gateway, Gelen requestleri bir mikro servisin birden çok intancesi arasında dağıtarak sistemin daha fazla sayıda requesti işlemesini sağlar ve genel performansını ve ölçeklenebilirliğini geliştirir.

𝗖𝗮𝗰𝗵𝗶𝗻𝗴: Mikro servislerden gelen responseleri cache alarak mikro servislere gelen  requestlerin sayısını azaltır ve sistemin genel performansını iyileştirir.

𝗠𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴: Requestlerle ve responselerla ilgili metrikleri ve diğer verileri toplayarak mikro servislerin performansına ve davranışına ilişkin değerli içgörüler sağlayabilir.Böylece  sorunları tanımlamaya ve teşhis etmeye ve sistemin genel güvenilirliğini ve dayanıklılığını geliştirmeye yardımcı olabilir.

Gerçek Dünya Senaryosu
Bir Mikroservis Mimarisi düşünelim:

• Load Balancer, trafik yükünü birden fazla API Gateway'e bölebilir.

• API Gateway, kimlik doğrulama ve yönlendirme işlemlerini yaparak, trafiği ilgili mikroservislere dağıtabilir.

Yani Load Balancer, genel sistem trafiğini yönetirken; API Gateway, API'lerin daha akıllı bir şekilde yönetilmesini sağlar.

API Gateway, mikroservis mimarisinde kullanıcı isteklerinin güvenli, hızlı ve etkin bir şekilde yönetilmesini sağlar. İstemcilerle mikroservisler arasındaki tüm işlemlerin tek bir noktadan yönetilmesi, güvenlik, izleme ve performans gibi alanlarda büyük avantajlar sunar. API Gateway’in sağladığı güvenlik ve yük dengeleme gibi özellikler, mikroservis mimarisinin karmaşıklığını azaltırken, sistemin daha ölçeklenebilir ve yönetilebilir olmasını sağlar. Ancak, API Gateway yapısını dikkatli planlamak ve ölçeklenebilir bir çözüm seçmek bu yapının performansını ve güvenilirliğini artıracaktı

Backend For Frontend

Bu model, aynı resourceyi  kullanan, farklı ihtiyaçlara sahip birden fazla client interfacesi  olduğunda iyidir. BFF modelinin gerçek dünyadaki bir örneği, hem Web hem de mobil clienta sahip bir uygulamadır. Her birisi için ayrı bir Api Gateway olacak şekilde ayarlanır. Örneğin Product Detay sayafası için hem web hemde mobil tasarlanacığını düşünelim. Bu durumda web sayfasında mobile göre daha çok detay bilgi bulunacağını düşünürsek iki istemcinin de aynı apiyi kullanması doğru olmaz. Burada mobil ve web için farkli gatewaylerin olması daha doğru olur. BFF kalıbı, her bir istemcinin farklı ihtiyaçları olduğu durumlarda çok etkilidir, çünkü her BFF istemciye özel optimize edilmiş veri sağlamak için çalışır.

BFF modeli, API ağ geçidi modelinin bir çeşidi olan mimari bir paradigmadır.

Api Gateway

.

BFF ve API Gateway Arasındaki Farklar

API Gateway ve BFF, her ne kadar istemciler ve mikroservisler arasındaki veri akışını düzenlemek için kullanılan katmanlar olsa da, temel işlevleri ve uygulama alanları farklıdır:

• API Gateway, tüm mikroservisler için tek bir giriş noktası sunar. Güvenlik, yük dengeleme ve genel veri dönüşüm işlemlerini gerçekleştirir.

• BFF  ise, her bir istemci türü için özel olarak yapılandırılmış backend işlevselliği sağlar. Her istemciye özgü iş mantığı, veri dönüşümü ve güvenlik politikaları BFF üzerinden yönetilir.

Bu iki yapı bir arada kullanılabilir. API Gateway, genel yönetim ve güvenlik sağlarken, BFF her istemciye özel iş mantığını üstlenir.

BFF’lerin API Gateway ile entegre çalışmasını sağlayarak tüm veri akışını daha düzenli hale getirin. API Gateway, istemcilerden gelen talepleri BFF’lere yönlendirirken, istemci türüne göre hangi BFF’nin kullanılacağını belirleyebilir

Reference 

https://www.codemag.com/Article/2203081/A-Deep-Dive-into-the-Back-End-for-Front-End-Pattern

Get data from microservices

Mikro servislerin faydası, Bağımsız olarak geliştirilmesi ve bağımsız olarak çalışabilmesiyle mümkündür. Mikro servisler arasındaki bağımlılıklar, micro servis mimarisini bize sunacağı faydayı azaltır.

Selective data replication, bağımlılığın scopunu en aza indirirerek  başka bir mikro servisin datasını kullanmamıza olanak tanır. Bu yaklaşımı kullanarak ihtiyacımız olan  datanın bulunduğu mikro servisin API'sine bağımlı olmak yerine data schemasına bağımlı oluruz. Yani ihtiyacımız olan datanın tablosunu bu micro servis içinde oluşturacağız.

Böylece geliştirme ve üretimde mikro servislerin bağımlılık maliyetini en aza indirmiş oluruz.

Giriş

Monolitik uygulamalarda, tüm verilerimiz tek bir ilişkisel veritabanında olduğundan dolayı datalara sorguları çok kolay bir şekilde yapabiliyoruz.

Micro servis mimarisiyle verilerimiz birden çok veritabanı üzerine dağıtılır. Her mikro servis  sadece kendi veritabanına erişebilir. Birden çok mikro servisten  gelen verileri birleştirmek için kullanıma hazır bir çözüm de yoktur.

1- Selective Data Replication

Bu yaklaşımla, diğer mikro servislerden ihtiyaç duyduğumuz verileri mikro servisimizin veritabanında replicasını oluşturuyoruz. (Yeni bir tablo açıp oraya kaydetmek)

Mikro servisler arasındaki tek bağlantı, data replication configuration olacaktır.

Publish-Subscribe Replication yaklaşımı kullanılarak veritabanı dataları güncellenir.

Advantages:

• Implemantationu basitleştirir. Verileri sorgulamak için REST çağrılarına gerek kalmaz. Ayrıca datalar micro servisin kendi veritabanınad olduğundan verileri birleştirmek için artık SQL Join kullanılabilir
• Test etmeyi basitleştirir. Mikro servis API'sini test ederken diğer mikro servislerin online olması gerekmez.
• Separation of concerns. Diğer servislerle olan veri entegrasyonu, mikro servis API'sinin implementasyonundan ayrıdır.
• Sorgu kriterleri, verileri tüketen mikro hizmet tarafından uygulanır. Artık ihtiyacınız olan sorgular için  verileri sağlayan mikro servise bağımlı değiliz. Tüketici mikro servisler kendi veritabanı sorgularını yapabilirler.(ihtiyaç duydukları kriterler ne olursa olsun). Bu, tüketen mikro servislerin gereksinimleri değiştiğinde verileri sağlayan mikro servisi değiştirme ihtiyacını ortadan kaldırır.Ayrıca, mikro servisleri tüketerek artık gerekli olmayan uzak sorgu API'lerini (tedarik eden mikro hizmetten) izlemeniz gerekmeyecek.
• Daha düşük latency. Diğer mikro servisleri http requesti atmak yerine verileri doğrudan veritabanından alabilirsiniz.

Disadvantages:

• Verilerin tutarlı olmaması. Replica eninde sonunda tutarlı olacaktır; Fakat her değişiklik için, verilerin mikro servisler arasında senkronize olmayacağı kısa bir süre olacaktır.
• Deployment processe  fazladan bir step eklenecektir. Veritabanı şeması değiştiğinde, microserisimiz  configurasyonun güncellenmesi gerekebilir.(taloya yeni bir kolon eklenmesi vs.)
• Aynı datanın farklı veritabanlarında dublicate olması. Servisler arasında ne kadar çok veri kopyalanırsa, bakım yükü ve veritabanı yedekleme(backup)  maliyetleri vb. o kadar yüksek olur.
• Veri güvenliğini sorununu arttırır. Birden fazla veritabanında ve muhtemelen mesajlaşma sunucunmzda da saklanan verilerin kopyaları olacaktır. Bu yaklaşım hassas bilgiler (ör. kredi kartı bilgileri) için uygun olmayabilir.

2- Direct Queries Between Microservices

Her bir mikro servis, ihtiyaç duyduğu veriler için diğer mikro servislere http requesti atar.

Bu, monolitic bir uygulama geçmişine sahip geliştiriciler için içgüdüsel bir seçimdir. Developerlar, local method çağrıları yerine   remote çağrılar yaparlar(ör. REST).

Advantages:

• Live data. Return edilen datalar microservisin current statetidir.

Disadvantages:

• Tightly coupled. Veriyi almak istediğimiz micro servise sıkı bir şekilde bağlanmış oluruz.
• Dependencyler online olmalıdır. Bir mikro servisin offline olması diğer servislerin çökmesine neden olabilir.
• İhtiyacımızdan daha fazla veriyi almak. Sadece EntityNam alanına  ihtiyacımız varken tüm entityi aldığımız durumlar yaygındır. Bu serialization/deserialization israfına yol açar

3-Composite Service Layer

Composite servis, low-level microservislerden dataları aggregate eder. 

Advantages:

• Low level microservisler birbirine coupled değildir. 
• Live data. Return edilen datalar microservisin current statetidir.

Disadvantages:

• Low level micro servislerde external dataya ihtiyaç duyarsa bu çözüm işe yaramaz.
• Composite servis kendi altındaki low level micro servislere tigth-coupled olacaktır. Servisler arası bağımlılığı composite servis üzerine taşımış olduk. Bu durumda composite servis dar boğaz sorunu oluşabilir.
• Dependencyler online olmalıdır. Bir mikro servisin offline olması diğer servislerin çökmesine neden olabilir.
• İhtiyacımızdan daha fazla veriyi almak. Sadece EntityNam alanına  ihtiyacımız varken tüm entityi aldığımız durumlar yaygındır. Bu serialization/deserialization israfına yol açar.
• More difficult to debug requests

4- Joining data in the user interface

Bu yaklaşımda user interface (UI)  ihtiyaç duyduğu tüm datalar için micro servis endpointlerine request atar.

5- Views between database schemas

Tamamen ayrı veritabanları yerine, her mikro servisin aynı veritabanında ayrı bir şeması vardır.

Disadvantages:

• The database is a single point of failure

How to request information from multiple microservices?

Front-end apisi Description, Relations, ve Prices apilerine subcribe olmuştur. O apilereden gönderilen eventlere göre kendi tablolarını update etmektedir. Front-end api dataları sadece bu eventlerle update edilmelidir.

REFERENCE

https://enterprisecraftsmanship.com/posts/how-to-request-information-from-multiple-microservices/

Nullable

C# Nullable value types, bir değişkenin bir değerinin olmasına yada null olmasına izin veren bir tür temsilidir.

Nullable, bir typedan sonra ? koyulurak yapılır. Örneğin, int? değerin bir integer veya null olabileceği anlamına gelir.

Nullable Value Type vs Reference Type

• Reference Typelar  null value destekler.
• Value Type  değişkenler, Nullable value type kullanılmadığında null valueyi desteklemez.

Örneğin, int için varsayılan değer 0'dır. Ancak 0 bazen geçerli bir değer olabilir. Bu durum bazen  hataya yol açabilir. Nullable typelarda, bir değeri yoksa değişkeni null olarak ayarlayabiliriz. Böylece değişkenin bir değerinin olmadığını ve olası hatalardan kaçınmış oluruz.

Dictionary

C# dictionary key-value çifrtini tutan bir structure(yapı)dır.

Initialization

C#'ta bir dictionary tanımlamak için  önce key türünü  ve value türünü belirlememiz gerekir.

Dictionary Operation

Duplicate values

Key uniq olmalıdır. Eğer aynı key eklenmek istenirse KeyNotFoundException fırlatılır. Bunun için containskey metodu ile kontrol edilir.

Get Value By Key

"Adam" keyine ait bir value varsa onu getir. Eğer dictiopnaryde öyle bir key yoksa geriye integerin default valusunu getir. İntegerin default valuesi 0 dır.

Case İnsensitive Dictionary 

✅ dict["hello"]
✅ dict["HELLO"]
✅ dict["Hello"]

Yukarıdaki şekilde her key aynı valueyi işaret edecektir.