ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか

SEA関西のドメイン駆動設計の講演を聞いてきた。
感想をラフなメモ書き。

【元ネタ】
第47回 SEA関西プロセス分科会「ドメイン駆動設計」#SEAKANSAI #kspinddd #dddjp - Togetter

ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索

Twitter / masuda220: 今日の資料、公開しました。 ?#SEAKANSAI? ?#kspinddd? ?#dddjp? " ドメイン駆動設計　実践ガイド" http://www.slideshare.net/masuda220/ss-1 … @slideshareさんから

ドメイン駆動設計 実践ガイド

View more presentations from 増田 亨

【1】増田さんによるドメイン駆動設計の話は、「エリック・エヴァンスのドメイン駆動設計」の本の目次に従って説明してくれたので、とても分かりやすかった。
OOAに関しては「実践UML」「アナリシスパターン」「ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUML」などを2000年代前半に勉強会で読みこなしていたから、ドメイン駆動設計では、オブジェクト指向設計をどのように生かしているのか、が理解できたからかもしれない。

増田さんの職歴を聞いた所、OracleのデベロッパーからJavaなどのオブジェクト指向設計へ転向したとのことなので、DOAの良さもOOAの良さもよく理解されているのだろう。
また、ドメイン駆動設計だけでなく、ICONIXやSpringによる実装も組み合わせたオブジェクト指向設計なので、要件定義から外部設計、実装に至るまでの経験が豊富なことは感じられた。

【2】ICONIXを解説している本は「ユースケース駆動開発実践ガイド」がある。
EnterpriseArchitectというツールを使った開発でこの本を参考にした。

ユースケース駆動開発実践ガイド: プログラマの思索

ICONIXの手法では、ロバストネス図がユースケースと実装に近い設計モデル(クラス図、シーケンス図)の間のミッシングリンクになるという主張が根底にある。
ロバストネス図なので、要件を設計モデルに落とす時に、バウンダリ・コントローラ・エンティティでシステムを設計していくとオブジェクトが見えてくるというのが肝。
OOAの利点である「要件から設計、実装まで一気通貫で開発できる」特徴が詳しく書かれている本だろう。

しかし、モデルの品質は本当に良いのか？という正当性は、ICONIXでもドメイン駆動設計の本でも弱いだろうと思う。
ドメイン駆動設計では、ドメインの専門家と開発者がモデリングしていったら、あるブレイクスルーで設計モデルが分析モデルに変わるという話があるが、ではその条件は何かと言われたら、正直きちんと書かれていないのではないと思う。

実際、増田さんの話では、AsIsモデルをモデリングするのであり、ToBeモデルはモデリングしないというお話もあった。
そのコンテキストは忘れてしまったが、多分、AsIsモデルを設計し、顧客の要求を聞き耳を立てて収集して考えていけば、AsIsモデルを修正していくに従ってToBeモデルへ変わっていくという考え方なのだろうと推測した。

でも、僕としては、多分その考え方は根本的な解決ではないだろうと思っている。
あるべきシステムのモデル(ToBeモデル)を作り出すには、OOAとかDOAとかそういう次元の問題ではないと思っている。

【3】増田さんのドメイン駆動設計の話を聞きながら、僕はER図の設計に置き換えたらどうなるか、と解釈しながら聞いていた。
概念モデルに相当するクラス図の設計に、ER図におけるエンティティ抽出の技法は有効に使えると思う。

「ドメイン」という単語自体がユーザが理解できる業務用語を抽出したオブジェクトであり、それはDOAならリソースというマスタ系テーブル又はイベントというトランザクション系テーブルに相当するだろう。
オブジェクト同士の関連は、DOAなら、外部キーという参照関係又は複合キーという連関テーブルに相当する。
双方向の関連つまり多対多の関係は3つ目のオブジェクトを入れるという解決法を示されたが、DOAなら連関テーブルという組み合わせテーブルを作るだけのことだ。

連関エンティティと関連クラス: プログラマの思索

また、ValueObjectは記録したデータを修正せず履歴を残していくパターンらしいが、DOAなら注文や請求などのトランザクションテーブルは、修正する時に赤黒伝票を作って訂正仕訳を起こすのと同じだ。

また、エンティティで重要なのはユーザが識別できる一意な番号を知っているかどうか、という話は、DOAなら自然キー(natural key)やT字型ERのIdentifierの概念と同じだ。
内部的なシーケンス、OIDはオブジェクトの識別子とならないという話は、DOAなら代理キー(サロゲートキー)やOracleのシーケンスなどと同じだ。

候補キーと2次識別子に関する概念: プログラマの思索

また、Entitiesの例の例として、伝票と記帳、残高の更新、人、組織、もの、場所があげられていた。
エンティティの洗い出しのパターンとしては、OOAならば「ストリームラインオブジェクトモデリング」で既に紹介されている。
オブジェクトは12個の種類に分類でき、その関連も全てパターン化されるというお話。

SL＝StreamLine Object Modeling: プログラマの思索

面白い指摘は、場所の識別は問題が複雑だということ。
場所エンティティを使いやすいモデルとして作るには、勤務者が利用しやすい所、利益が出るために最適な場所などの観点を入れる必要があるため、試行錯誤する必要があるらしい。

「Read the boook」(その手の本を読め)という話は、モデリングするには業務知識が必要という指摘に過ぎない。
典型的な業務知識は簿記や生産管理があげられるだろう。
個人的には、簿記3級と2級の知識があれば、小売業や製造業などの基本的な業務知識は身につくと思う。
それらの業務であるモノや情報の流れの背後には、必ずお金が絡んでいて、どの時点で売上や売掛金、買掛金や仕入れが発生するのか、という観点の仕訳が出てくるからだ。

クラスが多くなったら、クラスをまとめたモジュール図を重視するという話は、UMLならパッケージ図、コンポーネント図に相当するだろう。モジュールにまとめてモジュール間の関係を整理したいから。
JavaのJarの依存関係、WindowsのDLLの依存関係との話と同じ。
つまり、再利用可能な一つのコンポーネントとしてJarやDLLとまとめて、他プログラムから呼び出す機能の塊にするわけだ。

【4】OOAは2000年代前半はとても盛り上がっていたのに、最近はあまり広まっていない。
何故なのだろう？
でも、Railsが出現して以来、OOAよりもDOAの必要性が逆に高まっていると思う。
何故なら、テーブル設計さえできればすぐにマイグレーションを実行して、テーブル生成や新規データ投入後、すぐにCRUD画面ができてしまうからだ。
つまり、テーブル設計さえしっかりしていれば、残りの業務ロジックはRubyでサクサク作ってしまえばいい。

JavaのSAStruts、PHPのCakePHP、PerlのCatalystなどのようにRubyのRailsクローンと呼ぶべきWebフレームワークが主流となった今、モデリングにおけるDOAの重要性はもう一度再認識すべきだと思う。
自分の中でももう一度整理してみる。

【追記】
増田さんから下記の感想がありました。
上記はあくまでも一意見です(^^)

Twitter / masuda220: OOAとDOAって排他的な対立手法なのかなあ。私はたぶん厳密に区別せずにいっしょに使っている。RT @akipii: ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか http://bit.ly/Mjey6M