Her mikroservis mimari diyagramı temiz başlar ve bir yumak olarak biter. Neredeyse bir doğa kanunu. Servisleri çizersin, aralarındaki çağrıları çizersin ve yirmi kutuya varmadan ortada "karmaşık" demekten başka bir şey söylemeyen, kesişen oklardan oluşan okunmaz bir ağ olur. Sorun mimaride değil. Sorun, diyagramın tüm bağlantıları aynı anda göstermeye çalışması; oysa okuyucunun ihtiyacı olan şey yapının kendisi: sınırlar ve servislerin konuşma biçimi.
Çıkış yolu "her servis her servisi çağırıyor" çizmeyi bırakıp bilinçli olarak iki şey çizmek: servisleri gruplayan sınırlar ve her kenardaki iletişim tarzı. Bunu yaparsan büyük bir sistem bile okunaklı kalır.
Izgaraya göre değil, servis sınırlarına göre grupla
Yapabileceğin en büyük iyileştirme, servisleri düzgün bir ızgaraya dizmeyi bırakıp ait oldukları sınıra göre gruplamaya başlamak. Domain diliyle bunlar bounded context'lerin; ekip diliyle genelde neyin sahibi kim olduğu. Sipariş, Ödeme, Kimlik, Katalog. Bunları etiketli bölgeler olarak çiz ve servisleri içlerine bırak. Diyagram birden bir yapıya kavuşur ve okuyucu kırk özdeş kutuyu taramak yerine alan alan gezinebilir.
Mikroservis iletişimini her kenarda göster
Okların hepsi eşit değildir ve eşitmiş gibi davranmak, mikroservis diyagramlarının yanıltıcı olmasının sebebidir. Senkron bir istek (bir servisin diğerini çağırıp beklemesi), asenkron bir event'ten (bir servisin yayınlaması, diğerlerinin ne zaman olursa tepki vermesi) tamamen farklı bir hata ve gecikme davranışına sahiptir. Onları farklı çiz: senkron çağrılar için düz çizgi, bir bus ya da kuyruk üzerinden giden event'ler için kesikli. Artık diyagram operasyonel bir hikâye anlatır. Yavaş bir servisin nerede zincirleme etki yaratacağını (düz zincirler) ve sistemin nerede gevşek bağlı olduğunu (kesikli atlamalar) görebilirsin.
Farklı çizilmiş iki tür ok, bir yumağı hatanın nerede yayılıp nerede durduğunu gösteren bir haritaya çevirir.
Veri sahipliğini en az bir kez çiz
Mikroservisleri mikroservis yapan kural, her servisin kendi verisinin sahibi olmasıdır. Tüm servislerin tek bir veritabanını paylaştığını gösteren bir diyagram, ekip bunu istesin ya da istemesin, dağıtık bir monolit çiziyordur. Her servisin kendi deposuyla birlikte durduğu bir görünüme sahip olmaya değer; çünkü iki servis aynı veritabanını gösterdiği an, ileride canını yakacak bir bağımlılık bulmuşsundur. Bunu her diyagramda göstermen gerekmez, ama bir yerde göstermen gerekir.
Herkese ait kenarları ekle
Birkaç bileşen sınırların dışında durur ve her şeye dokunur: tüm sistemin önünde duran API gateway, asenkron trafiği taşıyan event bus ya da message broker ve kullanıyorsan servisler arası konuları yöneten service mesh. Bunlara diyagramın kenarlarında kendi yerlerini ver; böylece kutudaki bir başka servis gibi değil, paylaşılan altyapı olarak okunurlar.
Her şeyi çizme dürtüsüne direnin
Başarısız mikroservis diyagramı eksiksiz olmaya çalışır. İşe yarayan ise bilinçli olarak kısmidir. Diyagramın yanıtlayacağı soruyu seç (bir istek nasıl akıyor, asenkron sınırlar nerede, hangi servis hangi verinin sahibi) ve yalnızca ona hizmet edeni çiz. Eksiksiz ama okunmaz olan kimsenin işine yaramaz; odaklı ve net olan işin ta kendisidir.
Canlı tut
Mikroservis sistemleri diyagramını çizeceğin neredeyse her şeyden daha hızlı değişir: yeni servisler, yeni event'ler, emekliye ayrılan bağımlılıklar. Elle çizilmiş bir versiyon sprint bitmeden bayatlar. İskeleti kaynaktan (spesifikasyonlar, servis manifestleri ya da bir çağrı grafiği) türet, sistem geliştikçe yeniden üret ve sınır gruplamanla kenar stillerini üstteki insan katmanı olarak koru. Böylece diyagram, tüm vaadi bağımsız değişmek olan bir sisteme ayak uydurur.
Sınıra göre grupla, kenarları servislerin konuşma biçimine göre stillendir, veri sahipliğini bir kez göster ve tabanı güncel kalsın diye üret. Gözünü korkutmak yerine işleri netleştiren bir mikroservis diyagramı böyle olur.