JIGを利用したモデリングのすすめ

Adways Advent Calendar 2020 1日目の記事です。


 

こんにちは、広告システム担当の飛田です。1年ぶりの登場です。
Adwaysのアドベントカレンダー 今年も始まります!

ところで、モデリングの成果物であるドキュメント管理に悩まされたことはありますか?
今回は設計を支援するツール JIG を紹介します。

背景

所属部署ではドメイン駆動設計が浸透しつつあり、モデリングを行う機会が増えています。
一方で、モデリングで作成したクラス図などのドキュメント管理に問題がありました。

  • 必ずモデリングするわけではないため、ドキュメントの更新漏れが発生する
  • コードとドキュメントの内容が必ずしも一致している状態ではない
  • ドキュメントの更新にもコストはかかる

そんな中、偶然にも irofさんの コードをどまんなかに据えた設計アプローチ を拝見し、
JIGを試してみました。


 

JIGとは

コード中心とした設計を支援するツールです。
主にバイトコード(classファイル)から一覧やダイアグラムを出力します。
バイトコードが対象なので、JVM言語であれば主要機能は動作します。

JIGが想定するアーキテクチャは三層+ドメインモデルです。

ちなみに弊社の広告システムではScalaを使用しているため、
Yoshitakaさんが作られたsbt-pluginを利用します。

なお、ドキュメントの生成には主にバイトコードを使用していますが、
ソースコード(Java)の解析が必要なドキュメントは、Scalaでは生成できません。


 

セットアップ

project/plugins.sbt に下記を追加します。

resolvers += Resolver.jcenterRepo
resolvers += Resolver.bintrayIvyRepo("yoshiyoshifujii", "sbt-plugins")
addSbtPlugin("com.github.yoshiyoshifujii" % "sbt-jig" % "2020.11.1")

sbtのバージョンが 1.0.0 以上必要なので、0.13系を使われている方はこの際あげちゃいましょう!


 

Usage

設定はbuild.sbtに記述します。
プロジェクトに合わせて、各種パスやモデルパターンを変更してください。

jigDocumentTypeText in jig := ""
jigOutputDirectoryText in jig := "./target/jig" // 出力ディレクトリ
jigOutputOmitPrefix in jig := ".+\\.(service|domain\\.(model|type))\\." // 出力時に省略するプレフィックス
jigModelPattern in jig := ".+\\.domain\\.(model|type)\\..+" // ビジネスルールと認識するパターン
jigProjectPath in jig := "./" // 情報を読み取るルートディレクトリ
jigDirectoryClasses in jig := s"target/scala-2.12/classes" // 情報を読み取るディレクトリ
jigDirectoryResources in jig := s"target/scala-2.12/classes" // 情報を読み取るディレクトリ
jigDirectorySources in jig := "src/main/scala"

実行

sbt compile
sbt jigReports

 

実際に使ってみた感想

導入からドキュメント作成まで簡単にできました。
とても手軽にできるので、いつでも作りたてホカホカなドキュメントを味わうことができますね!

こちらが実際に生成されたビジネスルール関連図のダイアグラムです。(詳しくお見せできませんが...)
f:id:AdwaysEngineerBlog:20201201113621p:plain

関連の矢印が重なって見辛いですが、設計がよくないからでしょうか。
見るからに ドメイン層のパッケージの切り方が悪い ようですw

また、ビジネスルール関連図の他にパッケージの関連図も出力することができます。
f:id:AdwaysEngineerBlog:20201201113649p:plain

パッケージ単位での関連になっているので、ビジネスルール関連図よりはスッキリ見れます。
パッケージの関連図で全体を俯瞰し、ビジネスルール関連図で仰視するような使い分けが良さそうです。


 

問題の解決はできそうか

再掲

  • 必ずモデリングするわけではないため、ドキュメントの更新漏れが発生する
  • コードとドキュメントの内容が必ずしも一致している状態ではない
  • ドキュメントの更新にもコストはかかる

ドキュメントを保存管理しないので、更新に関する諸問題は解決しそうです。
また、コードからドキュメントを作成するので、内容は必ず一致した状態になります。


 

まとめ

業務での利用はまだ始まったばかりですが、モデリングや特にリファクタリングする際には
非常に有効なツールだと感じているので、活用したいと思います。


 

次はわたせさんの記事です。

blog.engineer.adways.net