この記事はハワイアンAdvent Calendar 2020 8日目の記事です。Mac miniが届きました。まだ普段使ってる ターミナルエミュレータ kitty をビルドしてざっと動かしてあーよかったとなった所で、他はなにもやってません。色々試したい気持ちを抑えながら、今このブログを書いています。

同僚から C4 Model についてのリクエストを受けたのでC4 Modelの話をしようと思います。いやー助かった。持つべき同僚は同僚。

みなさんはmicroservicesやっていってますか。今すぐ止めて、小さいアプリケーションを作りましょう。その方が幸せかもしれません。それはさておき、サーバサイドの開発でもクライアントサイドの開発でも、開発者間の意思疎通のためにしばしUMLを描く事があると思います。何を使って描いているんでしょうか。ホワイトボードに描いたりastah*だったりcacooだったりPlantUMLだったり。近年はFigmaに並ぶオンラインなデザインツールがたくさんありますし、なんでも描けると思います。わたしは基本的にPlantUMLを使いながら、どうしてもPlantUMLでは無理だなとなったら「テキスト作図 + Auto Layoutは夢なんですかね…」と悲しみに包まれながらFigmaで描く、という事をしています。Figmaはとっても便利なんですけどなんでもできるから逆になんかこう…なんだろうな…もやもやしますね。もやもやはしますが、意思疎通が取れる事が一番大事であり最低限なので良いと思うんです。

UMLを書いていると、以下のような症状になりがちです。

• 素直にUMLの記法に習って関連性を示す要素や矢印を書いていった結果、一貫性を失い、図中で示したかったものがなんなのか曖昧になってしまう
• 一貫性があったとしても、後の読者によって求めている情報量の解像度が違う為に、無駄なコミュニケーションが発生してしまう
• 意思疎通はできたけど出来上がったソフトウェアとのギャップが何故か大きい

それでもソフトウェア開発における図でのコミュニケーション、意思疎通は欠かせないでしょう。UMLがうまく描けない方への処方箋として実践UMLという本があるんですが、いわゆる鈍器本なのと、UMLを描くという点だけ考えるとmicroservices時代の処方箋としては内容が足りなくなってきたので、本当に興味のある人だけにしてください。どちらかというとソフトウェア設計パターンを学ぶ意味でおすすめしたい本です。

C4 Modelは、そういったUML界における課題に対するソフトウェアアーキテクチャ図の作図指針を示すモデルとして優れていて、課題に感じていた部分をうまく補えているんじゃないかなと考えており、実践中というステータスです。そちらについては追々ブログを書きたいなと思っています。

C4 Modelについての詳細は https://c4model.com/ だったり ソフトウェアアーキテクチャのためのC4モデル を見たほうが理解が早いです。読んで欲しい。どうしても読みたくない人の為に3行で書くとだいたいこんな感じです。

• Context図 -> Container図 -> Component図 -> Code な順で徐々に解像度の高い図を提供するアプローチを取る (Codeはoptional)
• これらだけでは補えない他の観点での図も必要あれば用意する(System Landscape図、Deployment図、Dynamic図)
• 大規模なソフトウェア開発の意思疎通に活用していこうな

加えて、考案者であるSimon Brown氏より Structurizr というツールが提供されています。まだ深く使いこんでいないのですが、Layoutは基本的にStructurizr Web上でGUIまたは独自のDSLで作図しつつ、またそれ自体がドキュメンテーションのために必要になる目次機能だったり検索機能だったりも含んでおり、非常に高機能に見えます。他のツール用のデータフォーマット(例えばPlantUML)にexportする機能もあって、まだまだ発展途上ですがとても良さそうに思います。

これのOSS版も提供されていて、いくつかのプログラミング言語によって作図する事ができます(本家は本家で独自のDSLがあります)。これをKotlinでやっていくプロジェクトとして structurizr-extensionsがあるのですが、直近のKotlinの動向を思うとKotlinらしくないDSLだなあとか、自分でも勉強がてら試したい事とか実践する中でアレンジしたい事がでてきたので、 structurizr-ktx というのを趣味で開発しています。こちらも進捗を残していきたい…。

気づいたら0時を回っていたので今日は終わりです。