Microservice mimarileri bence yanlış anlaşıldı.

SRP’den (Single Responsibility Principle) yola çıkılarak sadece tek bir iş yapan, kendi içinde koherent minnak servisler oluşturuldu. Sonra bütün bu servisleri HTTP üzerinden birbirine bağlayıp ortaya dağıtık bir cümbüş çıkardılar.

Aklı başında kimse bir sisteme microservice mimarisi ile başlamaz.

SRP yerine domain bazlı düşünmek lazım.

Oluşturulan uygulama kendi domainine tam anlamıyla hakim olmalı. Bu da o domain içerisinde bir modüler monolit olması anlamına gelir.

Örneğin:

– Identity bir domain → kendi monoliti

– CRM bir domain → kendi monoliti

– Commerce bir domain → kendi monoliti

– Communication bir domain → kendi monoliti

Her biri kendi verisine, iş kurallarına ve iç mimarisine sahip olur.

Asıl önemli nokta ise bu domainlerin birbirlerinden mümkün olduğunca bağımsız olmasıdır.

Domainler arasında gerçekten senkron bir cevaba ihtiyaç varsa API kullanılabilir. Ama bir domain içerisinde gerçekleşen bir değişikliğin diğer domainlere aktarılması gerekiyorsa, bunu HTTP çağrıları zinciriyle yapmak yerine event bazlı bir mimari tercih ederim.

Örnegin:

-> CustomerCreated

Event yayınlanır.

İlgilenen domainler bunu kendi ihtiyaçları doğrultusunda tüketir.

Böylece bir domain diğer domainin implementasyonunu bilmez. Hatta event’i yayınlayan taraf, kimin bu event’i tükettiğini bile bilmek zorunda değildir.

Ben bu yöntemle temelde klasik anlamda microservice olmayan ama tepeden bakıldığında bağımsız domain monolitlerinden oluşan bir mimari oluşturdum.

Buna kendi adıma:

Macroservice Event Driven Domain Based Monolith Architecture ;-)

diyorum.

Microservice’in küçüklüğünü değil, domain’in bütünlüğünü esas alıyorum.

Gidişat şu şekilde:

– Önce doğru domain sınırlarını çiz.

– Her domaini kendi içinde monolit olarak bırak.

– Domainleri birbirinden decouple et.

– Gerektiği yerde API, mümkün olduğu yerde event kullan.

– Dağıtık sistemin karmaşıklığını ancak gerçekten ihtiyacın olduğunda sisteme dahil et.

Tavsiye olunur ;-)