tmty.jp

先日仕上がったフレームワークの、背景となった業務ドメインモデルができるまでのメモ。実は別ブログに書いてあったものを再構成しただけ。が、この再構成を酔っ払った状態でやっているので、ちょっと意味不明かも。まあ、自分用のメモということで御容赦いただきたい。今に、もっと直すかもしれません。

さて、

今の出向会社に来た当初は、業務そのものを理解できていなかったのだが、長く居るうちに全社的な業務を見渡せるようになってきた。ITアーキテクトか何かに載っていたようなシステム構成図の表現技法を見よう見まねで書いてみたら、なかなか面白い絵になった。

続けて JUDE で適当な粒度のアクティビティ図を書いてみた。(作業レベルで)共通化している部分を切り出しながら、こりこり書いていたら、全部で 15 枚弱になった。ビジネススクールで学んだバリューチェーン図に並べてみると、収益/コスト構造が一目瞭然。だいぶ見通しが良くなった気がする。

アーキテクトの先輩に相談したら、もう一段階粒度の大きい、全社的な業務アクティビティを整理することを提案された。自分の中では大きめに書いていたつもりだったが、トップダウンな視点で見るには、確かにもう一段階足りなかったようだ。
ついでに、個別機能単位の設計については、input/output の視点、具象/抽象 の視点での歩み寄りと妥結点の模索についてアドバイスを貰った。こういう的確なアドバイスが出せるようになりたい。

で、さっそく粒度の大きいアクティビティを整理し、続いて、ここからロバストネス図作成へ進めていった。ユースケースをしっかり書いておくべきだったが、当時は諸事情によりとある機能実装の見積もりを進めなければならないという状況でもあった。

状況が状況だったので、結局そのままロバストネス図を起こしてみた。なんだかそれっぽいモノができたが、さて、これをどう分析に使うものか分からない。

既存のシステムと新規案件で構築するシステムとで、どう切り分けながら、どの範囲を設計すれば良いか、その落としどころも良く分からない。端的にいえば、部分最適を優先するか、全体最適を優先するか、のトレードオフという状態だった。結局当時は、的確な決定を仰ぐところまで行き着くことができず、全体最適の志向で分析を進めていった。

余談だが、先輩エンジニアが言うに、全体の分析をしっかり進めておいた後の、その後の恩恵は非常に大きい(逆に言えば、部分最適ばかり進んでしまうと、全体の抽象化、最適化にかかる調整コストが倍以上になる)事は認識しておいたほうが良いとの事。実際にコードを書く立場になることを考えれば、確かにこれは想像に難くない。これを覚悟の上で部分的な開発を進めるのであれば、既存のシステムに一切手を付けない(後からインタフェース変換部分を作る)つもりで、完全に独立させることを意識したほうが良い、ともアドバイスを貰った。

続いて、作成した図を用いたロバストネス分析。開発対象のオブジェクトを適切な単位に分割・統合するために行う分析・設計プロセスだ。UML を使ったプロセスで言えば、ユースケースからクラス図への落とし込み .. このときの仲介作業に当たるものになる。

オージス総研の「実践ロバストネス分析」 が参考になるが、僕の解釈とは少し違う説明になっているようだ。まあ、意図するところは同じなので、細かいことはあまり気にしないことにする。

まず、先に描いてきた各アクティビティを、バウンダリ、コントロール、エンティティ単位に分割して書き下してみる。バウンダリはインタフェースに当たるもので、必ずしも画面(UI)単位ではないことに注意したい。手始めに書いてみる分には画面単位で書いてみるのが直感的で良いかもしれないが、最終的にインタフェースベースの設計をする事を考えれば画面単位で分割してしまうのは適切とはいえない。

バウンダリ、コントロール、エンティティ間の関連は方向が決まっている。

バウンダリ -> コントロール -> エンティティ
|               |                 |
v              v                 v
バウンダリ -> コントロール -> エンティティ

基本的にはこの 5 方向しかない。コントロールからバウンダリ、エンティティからコントロールへ向かう(左向きの)関連が出てくるようでは単位が適切でないということになる。そういう意味では、バウンダリ、コントロール、エンティティはそれぞれ、View, Control, Model に(大体)対応していることがわかる。「関連」を uses とか depends のような動詞と考えてみれば、幾分か描きやすくなることもわかった。

ロバストネス図が大体描けたら、いよいよ分析フェーズ。ここからクラス図へ落とすことを想定し、(殆どの場合) エンティティを一クラスに見立て、CRC カードを書いてみる。CRC とは Class, Responsibility, Collaborator の略で、一枚のカードにひとつのクラスと、そのクラスの責務、協調する(させる)クラスを書いていく。余談だが、「責務」という表現をする事は、適切なオブジェクト単位を括りだすための有効な手段だと思う。

CRC に書き出した際、一クラスの Responsibility はひとつ、Collaborator は多くても 3 つ程度になっていることが望ましいようだ。一クラスに多くの責務を負わせすぎると実装が肥大化してしまうし、協調者が多すぎるのもメンテナンス性を下げてしまう(というか、そのクラスの責務が薄れてしまう)。したがって、このような分割単位になるようであれば、ロバストネス図に立ち戻り、バウンダリ、コントロール、エンティティの単位と関連を見直し、再構成を行う。

クラスに落とす際に、有効なデザインパターンを採用するのもテクニックのひとつだが、それには有効なデザインパターンが提案できるだけの知見が必要になる。こうして、なんとなくやるべきことが見えてきた。

そんなこんなで、クラス図とロバストネス図、ユースケースの行ったり来たりと、各種デザパタの適用を繰り返していくうちに、今のドメインモデルの素案ができあがった。

今から半年前の話。いろんな会社のケースでこういうののトレーニングを積むのも面白そうだ。

以上、振り返り終わり。