なんかぼんやり思ったので自分用にメモ。特に強い結論があるわけではない。
よくある
- 概念モデル
- 論理モデル
- 物理モデル
ってやつ。
物理モデルについては ActiveRecord + Rails-ERD などで作り方を逆転させることも可能。これに慣れると抽象的なモデリングってほんとに必要なのかなという気もするけど、それはたぶんプロダクトの特徴を熟知しているから可能なのであって、何をしようとしているのかさえ不明瞭な状態ではいきなりは無理。
概念モデル、論理モデルはコミュニケーションのためのものと割り切ればよいのかもしれない。
概念モデルはやりたいことに名前を付けて、必要そうなシステムを洗い出すためのもの。
論理モデルはその際に必要になるデータの制約に注目するためのもの。何と何が紐づいているので、とか、どういう変更がどのタイミングで入るのか、とか、絶対に欠落したらダメとか。
いずれもコミュニケーションのためなら母語で書かれてよい。ただ、論理モデルで考えてる制約の話は物理モデルから出てきている部分があって、やはりもやもやは残るんだけど、頭の中である程度の物理モデルが作れる人が論理モデルで会話できるようになる、ってイメージかなぁ。物理モデルの経験がある程度以上ないと論理モデルが挟まるのは単に面倒が増えるだけというか、逆に難しい感じがする。
物理設計はパフォーマンスまで考えるって話があるけど、正規化してる段階でパフォーマンス考えてますよね、とか、なんかもやもやを感じたもので。はい。
いや、はい。だから特に結論はないってば。
draw.io – Online Diagramming
特徴
- 日本語も使える
- 開発者向きのドローツールとしてある程度利用可能なレベル（単に丸や四角や三角と文字が描けるレベルではない）
- Google Drive, Dropbox, GitHub (!) など様々なストレージを利用できる
- なんならローカルにも保存できる
カジュアルに使い始めるのに本当によさそう。
G Drive / Dropbox連携
当たり前だけど他のデータと同様、片付け場所に困る気がする。使い始めるのはよいけど、のちのち困るパターン。特にチームで共有するような場合。
逆に複数のチームに出入りするフリーランスのような立場だととりあえずこういう形ででも共有できると嬉しい気がする。
GitHub連携
branchには保存できないっぽいので、ドキュメント用のrepositoryがあった方がよいような感じがする。
GitHub ベースで議論する際に「設計図は G Drive」へ、と分断があると割とつらいんだけど、画像で export するとこの問題は回避できそう。保存形式は draw.io 独自の XML のようなものでもできるし、画像としての export もできる。ただまぁ、図だけ共有できてもダメなので、開発プロセスすべて GitHub に寄せてくれ、を実現することはたぶんできない。
とは言え、GitHub を中心に活動するエンジニアが自分たちのために図を残すには十分使えると思う。
参考
- draw.io で書いた画面設計書いてみたらストレスフリーになった 〜 続・gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ
- gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ
- Pegmatite
懸念
draw.io は今のところ confluence / JIRA connect 以外は無料で使えてしまう。サービスの永続性がどれくらい本気なのかよく分からない。とっとと課金させてほしい。
逆に無料ツールとして導入してしまうといずれ有料化した時にどうするのかを判断する必要がある。