Yazılım mimarisini görselleştirmek için C4 modeli (2017)
(c4model.com)- C4 modeli, yazılım mimarisi diyagramları oluşturmak için geliştirici dostu bir yaklaşım sunar; karmaşık yapıları adım adım bölerek görmeyi sağlar
- Soyutlama software systems → containers → components → code sırasıyla aşağı iner ve mimariyi katmanlı biçimde ele alır
- Diyagramlar da system context → container → component → code yapısını izleyecek şekilde düzenlenir
- Gerektiğinde system landscape, dynamic, deployment diyagramlarıyla genel yapı ile çalışma ve dağıtım bakış açıları tamamlanır
- Belirli bir gösterim biçimine veya araca bağlı olmayan notation independent, tooling independent bir yöntem olduğu için mevcut ortama uyarlanarak uygulanabilir
C4 modelinin yapısı
- C4 modeli, yazılım mimarisini görselleştirmeye yönelik bir modeldir ve yaratıcısı Simon Brown’dır
- Temel nokta, katmanlı soyutlama ile katmanlı diyagramları birlikte kullanmasıdır
Diyagramlar ve bağımsızlık
- Temel diyagramlar, mimarinin farklı derinliklerde görülebilmesi için düzenlenmiştir
- Yardımcı diyagramlar, yalnızca temel katmanlarla eksik kalan bakış açılarını tamamlar
- Model notation independent ve tooling independent olduğundan, belirli bir gösterim biçimini veya araç seçimini zorunlu kılmaz
- İlgili kaynaklar arasında, Temmuz 2019’da “Agile on the Beach 2019”da kaydedilen Visualising software architecture with the C4 model videosu ve The C4 model materyali bulunur
1 yorum
Hacker News yorumları
Mimari diyagramların en büyük sorununun kod tabanıyla uyumsuz hale gelmeleri olduğunu düşünüyorum.
Bu tür diyagramların otomatik üretilmesi gerekir. Aksi halde ekibin, baktığı çizimin sistemin güncel durumunu doğru yansıtıp yansıtmadığını bilmesinin bir yolu yoktur.
Diyagramlar belirli bir bakış açısını gösterir; bazı özellikleri vurgular, bazılarını atlar. Aynı konu için farklı yönleri veya senaryoları açıklayan birden fazla diyagram olabilir. Sonuçta diyagramlar da metin dokümanları gibi kod ve uygulama mimarisiyle birlikte bakımı yapılması gereken şeylerdir; değişiklik yönetiminin düzenli işlerinden biri haline getirmekten başka çare yoktur.
Pek çok projede kod, zihindeki modelle aynı şekilde yapılandırılmaz ve neredeyse hiçbir dil bunu çözmenin bir yolunu sunmaz. Koda yorumlarla işaret koymak da diyagramları, yorumları ve dokümanları güncel tutmakla aynı sorunu taşır.
Mevcut durumu değil, hedef durumu gösterirler. Kod diyagramı izlemelidir; tersi değil. Koddan diyagram üretmenin anlamlı olduğu durum, dokümansız bir projeye yeni katılan kişiye yardımcı olmakla sınırlıdır; o zaman bile bir kez üretip gürültüyü temizleyerek düzenlemek ve sonrasında referans doküman olarak kullanmak gerekir.
Yüksek seviyeli diyagramlar hızlıca oluşturulup atılabilmelidir; neyi gösterdikleri kadar neyi dışarıda bıraktıkları da önemlidir.
C4 hoşuma gidiyor. Eskiden “User -{do their job}-> System-of-Record” gibi bağlam diyagramlarını işe yaramaz bulurdum, ama artık nedenini anlıyorum.
Karmaşık bir sistemin yeni tasarımını genişletilmiş ekiplerle C4 üzerinden yürütüyoruz. Bu kez en üst seviye çizimi yaparken, web UI dışında bağlantısı yarı kopuk olabilecek bir mobil uygulama da olduğunu fark ettim; çevrimdışıyken ya da backend yavaşken belirli bir sonuç henüz yoksa bazı davranışların zarif biçimde düşürülmesi gerektiğini anladım. Bu, bir sonraki katmanda iş kuyruğuna, oradan da tekrar UX’e bağlandı ve hangi isteklerin tamamlanmasının belirsiz süre alabileceğini açıkça söyleyebilir hale geldik. Eninde sonunda buna ulaşırdık, ama analiz bu sorunu doğrudan önümüze koydu. Çünkü tüm mesele “Remote-User --{Mobile Stuff}--> Backend” çizimini yapmak zorunda olmamızdı. Hangi aracı kullandığınız önemli değil; ben örneğin draw.io’da katmanlara göre sekmeler ayırıyorum. Daha somut hale gelince alt katmanları ayrı dosyalara böleceğim.
Diyagramlar için biçimlendirilmiş bir sisteme gerek olmadığı yönündeki argümanı da anlıyorum, ama C4’ün oldukça hafif olduğunu düşünüyorum. Ben kod seviyesine kadar inmiyorum.
Yine de C4 diyagramları üreten structurizr üretkenliğimi ciddi biçimde artırdı. Tek bir modelden farklı ayrıntı seviyelerinde görünümler üretme yaklaşımı; her diyagramın aynı bileşenleri bağımsız olarak tekrar tekrar tanımlamak ve yeniden tanımlamak zorunda kaldığı mermaid ya da plantuml gibi araçlarla karşılaştırıldığında harika. Branch alıp modeli değiştirip fikri sunma akışı bana çok uygun geldi.
C4’e katı biçimde ait olmayan kavramları çizmenin bir yolu yoktu. Örneğin iki bileşeni tek bir kutuya koyarak şu anda tek bir servis olarak dağıtıldıklarını ifade etmek istedim, ama mümkün olmadı. Bunun mutlak anlamda iyi bir tasarım olduğu söylenemez, fakat ekibin anlamasına yardımcı olurdu. Mimarinin biçimsel olarak tanımlanması fikri güzel, ancak diyagram çıktısında özelleştirme eksikliği çok zorlayıcıydı.
Mimarinin tanımını yapıyorsunuz, structurizr diyagramları render ediyor.
Yapılabilir, ama oldukça zahmetli; kutular arasındaki ok açıklamaları uzadığında otomatik yerleşim hızla bozuluyor.
Yazılım mimarisini, uygulamaya yön veren tasarım kararları kümesi olarak görme eğilimindeyim
Deneyimime göre çoğu yazılım mimarı, yazılım mühendislerine yönlendirme ve yapı sunar. Ama C4 açıklamasındaki “mevcut kodun farklı ayrıntı düzeylerinde haritasını çıkarmak” sözü kulağa farklı geliyor. Kod diyagramına neden yazılım mimarisi dendiğini bilmiyorum. Bu kelimenin tam anlamıyla kod düzeyi; nasıl mimari oluyor, anlamıyorum. Bu, bir evin planına priz içindeki devre şemasını koymayı önermek gibi. “Otomasyon araçları kullanılmalı” deniyorsa mevcut kod tabanını fonksiyon düzeyinde belgelendirmek mi kastediliyor? Bunun yazılımı tasarlamak ve planlamak için nasıl yararlı olduğunu bilmiyorum. Mevcut yazılım yapısını açıklayan bir harita güzel olabilir; ama tasarım kalıplarından bahsederken singleton uygulamasını fonksiyon bazında harita olarak sunmayız. Singleton ya da repository pattern gerektiğini söylemek yeterlidir. Yazılım tasarımının kendisi elbette var ve bu yaklaşım da tasarım için makul görünüyor; ama deneyimime göre yazılım tasarımı, uygulama ve mimari aynı şey değil, aynı kişiler tarafından da yapılmıyor. Bu daha çok sistem tasarımına yakın görünüyor; yazılım mimarı da o sistem tasarımının iyi mimari ilkelerle uyumlu olmasını tavsiye eden kişi olur gibi. Fazla didikliyor olabilirim
Geliştiricinin her seferinde kararı bir otoriteye devretmek yerine kendi tasarım kararlarını verebilmesi için bilgi sağlamanın, yazılım mimarisinin temel bir rolü olduğunu düşünüyorum. Ancak mimarinin nerede bittiği ve geliştirmenin nerede başladığı çok değişir. Bence mimarinin kendisi, mimari bakış açısından neyin önemli olduğuna karar verir. Mimari, düşük seviyeli bir uygulama ayrıntısının önemli olduğuna karar verirse o da mimari ayrıntısı olur. Pratikte çoğu organizasyonda mimari en azından bileşenler, iletişim örüntüleri, API’ler ve kullanılan teknolojiler gibi üst düzey tasarımı kontrol eder. Bazı organizasyonlarda tek tek sınıflara kadar iner. Tüm sınıflara değil; problem alanını modelleyen sınıflara, özellikle de bu model birden fazla projenin dili olarak kullanılıyorsa ya da paylaşılan bir çıktı olarak uygulanıyorsa. C4, uygulama ve entegrasyon arayüzleri listesinin ötesinde daha düşük seviyeli yapıları da mimari ilgi alanı olarak gören organizasyonlara uygundur
Temel olarak sistemde belirgin biçimde kendine özgü ya da yararlı olan her düzey için bir diyagram bulundurmak demektir. Kod düzeyi diyagramı gerekiyorsa muhtemelen karmaşık, özel bir iş yapıyorsunuzdur ya da uygulama ayrıntısı olarak bırakılabilecek tasarımı gereğinden fazla belirtimliyorsunuzdur
Gerçek hayattaki gayrimenkul inşaatında da mimar, mühendis ve şantiye şefinin rollerinin farklı olmasına benzer. Mimari, tasarım ve uygulamanın her birinde çizginin nereye çekilmesi ve hangi konuların ele alınması gerektiğini merak ediyorum
İlginç ama özellikle yeni bir şey kattığını söylemek zor
Üst düzey diyagramlar iyidir, ama şık bir görsel model web sitesi okumadan da zaten yapılabilir. Site de aslında bunu kabul ediyor. Sektörde UML, ArchiMate, SysML var ama birçok ekibin çok daha basit “kutu ve çizgi” diyagramlarını seçtiği tespiti çok doğru. Fakat UML sınıf diyagramının neden tamamen başarısız olduğunu görmezden gelmiş gibi. Kimsenin sevmediğini kabul ediyor, ama modelin dördüncü C’si olan kod, sonuçta UML sınıf diyagramı oluyor. Böyle şeylere gerek yok. Rastgele bir diyagramı net çizin ve oklara etiket koyun, yeter. İlk üç diyagram aslında bunun iyi örnekleri
Yeni kavramları düşünürken ya da beyin fırtınası yaparken de aracın ayağıma dolanmaması çok yardımcı oluyor. Şu anda Freeform kullanıyorum; çok basit ama iyi çalışıyor. İki nesneyi seçip cmd-tıklama ya da sağ tıklama sonrası “add connecting line” demek yeterli
Daha birkaç ay önce de sınıf diyagramları, sequence diagram’lar ve use case’lerin yeterince yer aldığı bir mimari dokümanı yine tamamladım
Kutular kolayca farklı düzeylerdeki şeylerin birbirine karıştığı bir duruma geliyor. Bazıları soyut, bazıları somut, bazıları ise sadece keyfi oluyor. Bu yüzden örneğin tedarik zinciri gibi daha büyük mimari parçaları bir araya getirmek gerektiğinde neredeyse her şeyi baştan yapmak gerekiyor. Çok israf yaratıyor; ayrıca tüm mimariyi yeterince net gören kimse de olmadığı için başka israf ve kalite sorunlarına yol açıyor. Garip şekilde birçok mühendis daha biçimsel yaklaşımlara savunmacı tepki veriyor; sanırım bunun nedeni ya anlık bir fayda görmemeleri ya da büyük ölçekli mimariyle uğraşmadıkları için sorunu fark etmemeleri
Bu, yazılım mühendisliğinin hâlâ olgunlaşmamış bir alan olduğunu gösteriyor
Benim durumumda 25 yıldan fazla zaman geçtiği halde hâlâ “temel” sayılabilecek aynı tartışmaları yapıyoruz. Bu kötü demek değil; ama ilerleme yavaş ve bunu sadece belirli bir şirkete, konsorsiyuma ya da ticari çıkarlara bağlamak da mümkün değil
Birinin tek bir düşünce içinde yüksek ayrıntı ve yüksek karmaşıklık ile uzaktan bakınca görülen sadelik arasında sürekli gidip geldiği için ne demek istediğini anlamakta zorlandığınız kaç kez oldu? Bir geliştirici “şu tahtaya kutular ve okları uygun şekilde çizmem yeter, benim kafamda anlamlı olduğu için iyi bir diyagram” diye düşündüğünde de aynı sorun ortaya çıkıyor
İnşaat mühendisi olmasanız bile kat planı gibi şeyleri hemen anlayıp yararlı bulabilirsiniz
Ama profesyonel bir yazılım mühendisi olduğum halde bu örnek diyagramlar harcanan çabaya değecek kadar yararlı ya da yeterince bilgi verici görünmüyor. Kod fazla çok boyutlu olduğu için 2 boyutlu bir çizimle yaklaşık olarak ifade etmek zor ve iyi çalışmıyor. Potansiyeli olan şey, daha çok standartlaşmış mimari kod kalıpları. Structured concurrency gibi şeyler ve belki ondan daha üst düzey bir şey olabilir
Kat planında bağlam çok sabittir ve kapsam sınırlıdır. Örneğin pencereyi açıklamanız gerekmez. Ama yazılımda çoğu zaman “pencereyi” gerçekten açıklamak gerekir. Tüm “pencereler” ya da öğeler birbirinden farklı olduğu için, sadece bunun pencere olduğunu söyleyip 20 kez kopyalayamazsınız
C4 modelinin fazla keyfî ve aşırı derecede spesifikasyon odaklı olduğunu düşünüyorsanız, bu yılın başlarında alternatif bir uygulama yöntemi hakkında yazmıştım: https://www.ilograph.com/blog/posts/concrete-diagramming-mod...
Bu modeli seviyorum; güvenlik mimarisinde UML kullanmak zorunda kaldığım zamanlar da oldu. Çünkü o tarafta en üst düzey bağlamdan koda kadar tutarlılık temel konu
C4 modelinin sadeliği bir tür zorlayıcı mekanizma. Gizli bir bağlam ya da bileşen varsa modelin içinde görünür hâle gelmeli. Bu kadar basit bir şeye bile direnç varsa, bunun gizli unsurlar olabileceğine dair bir işaret olduğunu düşünüyorum. Büyük projelerde de genellikle gerçekten böyle unsurlar oluyor. İnsanları bu şekilde düşüncelerini netleştirmeye zorladığınızda, yalnızca önerip eleştirme hakkını saklı tutmak yerine beyanlara ve fikirlere bağlılık göstermelerini sağlarsınız; böylece yetki dağıtılmış olur. Buna karşı da çok direnç doğabilir. Ancak bu modelin sorunu değil, model insanlarla karşılaştığında ortaya çıkan bir durum. Tutarlılığını sevdiğim için, güvenlik tasarımında referans olarak bu tür bir yaklaşımı kullanırım gibi geliyor
C4 çok ilginç ve yazılım mimarisindeki belirli bir sorunu iyi ele aldığını düşünüyorum
Mimarlığın alt katmanlarını, yani çoğunlukla donanım ve sistem yazılımını geniş bir soyutlamaya bırakıp, çabayı bunun üzerindeki yığında yer alan şeylere odaklamayı sağlıyor. Günümüzün bulut tabanlı, konteynerleştirilmiş ve ölçeklenebilir yaklaşımına şaşırtıcı derecede iyi uyuyor. Bununla bağlantılı olarak ArchiMate de iyi ve çok fazla örtüşen yanı var, ancak altyapı tarafına daha sağlam basıyor. Geçmişte ArchiMate’e benzer bir diyagram yaklaşımını kullanarak sistemler ve veri kaynakları arasındaki çatışmaları azaltmada, ayrıca satın alıp entegre ettiğimiz şeylerin belirli iş ve kullanıcı iş akışı gereksinimlerini nasıl desteklediğini göstermede büyük fayda görmüştük. Bunların kod tabanıyla uyumsuzlaştığı sözü tamamen doğru. Ancak karmaşık sistemleri analiz etmeniz ya da sistemleri ve planları daha büyük gruplara aktarmanız gerektiğinde harika araçlar olabilirler. Şaşırtıcı derecede sık şekilde hiç bütünlüklü dokümantasyon bulunmaz; birkaç hafta boyunca oturup kutular ve bağlantı çizgileri çizmek bile ilerleyemeyen bunaltıcı işleri çözebilir ve basitleştirebilir. Özellikle birden fazla ekip aynı alanda çalıştığında bu geçerlidir. C4, ArchiMate, UML vb. yalnızca aktarmak, analiz etmek ve kayda geçirmek istediğiniz belirli şeyleri yakalayan kısıtlı diyagram dilleridir. Ön planlama ya da tasarım araçları olarak pek iyi olduklarını düşünmüyorum. Birçok kişi devasa UML modası döneminde çok çekti. Baş mimar ekibinin, tek satır kod yazılmadan önce sınıf tanımlarına kadar sistemin her yönünü acı verici ayrıntılarla ortaya koyması gerektiği düşünülüyordu; “diyagramdan kod üretiriz” türü bir çılgınlık sayısız insanı bezdirdi. Gerçek kodlama başladığında ise o binlerce saatlik planlama genellikle göz ardı edildi ve geliştiriciler sonunda istedikleri gibi yaptılar