<< 良いアーキテクトとは? (ドメイン駆動設計的アーキテクト論) | main | アーキテクトは「パターン言語」を使う >>

Domain-Driven Design を読み終えて

去年の11月くらいに DDD を読み直しながら、自分の頭を整理するために、ブログで、DDD ネタをいろいろ書いてきた。

500ページ、17章を、ようやく読み終わった。お疲れさまでした、という感じだな。

何度も読み返してきたけど、ちゃんと通読したのは、今回がはじめて。
今までの読み方が甘かったのが、とてもよくわかった。

まあ、新鮮な発見がいっぱいあって、何か、新しい本を読んだような気分でもある。

自分たちが実践していること、できていること、できていないことも含めて振りかえってみて、改めて、Domain-Driven Design について、思ったことを、書き留めておきたい。

モデル駆動設計


DDD 前と後で、自分にとって、一番の発想の転換は「モデル駆動設計 ( Model-Driven Design )」に目覚めたことだった。

この本に出会うまでは、自分は、徹底的にコード命。エディタだけが、唯一の設計・実装ツール、という感覚だった。
UML とか、デザインツールとか、手はだしてはいたが、ただのお試し。
実際の、開発の仕事では、一切使わず、暇なときに、絵を描いて遊んでいた、という感じ。

DDD を最初に読んでからも、数年は、DDD が、なぜいきなり「モデル駆動設計」が重要なパターンとして登場するのか、ぴんときていなかった。

発想の転換のきっかけは、Domain-Driven Design ではなかった。

ユースケース駆動開発実践ガイド で解説されていた ICONIX プロセスを、現場で、やりはじめてから。

ロバストネス図を、若手に描かせてみて、自分と発想がまるで違うことを発見したとき。
そして、オレだったら、こんな感じにするよ、というポイントを、ちょっと手書きしたら、相手が「なるほど」と一発で、こちらの設計を理解した。

3年くらい前のできごとだったけど、今でも、その小さな会議室で起きたことが、まざまざとよみがえるくらい、強烈な印象だった。

それまで、ずーと「コイツは、なんでこういうコード書きたがるかなあ」と理解できなかったこと。
ここは、こういう書き方でしょう、といっても、相手に全然伝わらず、若手に設計スキルを伝える方法がわからず苦しんでいた。

それが、一枚の絵で、あっというまに解決した。なるほど、そう考えていたか、がこっちもぱっとわかったし、相手も、ぱっとわかってくれた。

一枚の絵が、設計意図の伝達に、手軽で便利な手段という、この事件(?)の印象は、ほんとうに強烈だった。

ICONIX プロセスは、ドメインモデリング(概念クラス図)を中心にした方法論だったこともあって、DDD の実践方法として ICONIX を現場で実践する、ということに、急激にのめりこんでいった。

ICONIX は、最小限の絵だけは、ちゃんと描こう、という軽量なやり方なのも、良い感じだった。

コードを書く前に、手書きでいいから、絵にして、話しをしてみよう、というのが、「モデル駆動設計」ということなんだと思った。

今でも、メンバーのマインドは、「コード中心」から完全に抜け出せたとはいえないかもしれない。

でも、「絵を描くことで設計意図が伝わる、ありがたさ」を体験しながら、そういうやり方が、だんだん、自分たちのやり方になってきた手ごたえがある。

最近になって、それなりの技術者たちと仕事をして、ロバストネス図の作成とレビューをちょっと、やってみただけで、相手の設計の考え方がすぎ理解できたし、こちらの設計意図も、簡単に伝わった。

こういうのが当たり前になってきちゃうと、DDD 前の、コードとエディタにどっぷりとつかっていた自分がいたのが、信じられないくらい。

この感じは、実際にやってみると、すぐ、伝わるんだけど、本を読んでいるだけでは、(私もそうだったけど)ぴんとこないんですよね。

ユビキタス言語


やっぱり、DDD の基本中の基本はこれでしょうね。

チーム内での会話、コンテキスト図やロバストネス図、パッケージ・クラス・メソッド・変数の名前、スキーマ・テーブル・カラムの名前、...

開発の現場の、ありとあらゆる場面に、ドメインの用語・概念が、頻繁に登場すること。できれば、それ一色になること。

それが、ドメイン駆動設計を実践する、ということなんだと思う。

これは、私自身は、Domain-Driven Design に出会う前から実践していたし、こだわっていた。

まあ、DDD に出会ってから、さらに過激になったとは思うけど、良いソフトウェアは、わかりやすい名前から、というのは永遠の真実だと思う。

そして、わかりやすい名前というのは、アプリケーションのドメインで使われる言葉なんです。

ここらへんは、20数年前に、C 言語で格闘していた時に、師匠にうるさくいわれたこと、15年くらい前の,
Oracle 時代に、設計ハンドブックで、業務用語を積極的にテーブル名、カラム名に使う設計・実装の流儀にであったこと、などの影響が大きい。

技術者だけが理解できる命名は、基本的に、よくない、わかりにくい名前。
業務の関係者が理解できる用語を使ったソースコードが良い設計。

ドメイン駆動設計の根底にあるもの


モデル駆動設計とユビキタス言語は、テクニックや方法論として、チームに浸透させることができる。
実際に、現場で取り組んできて、やってみれば、開発メンバーが、その良さを具体的に実感できることは実証できた。

自分たちは、ドメインロジックは、ドメインモデルパターンを重視するし、実装のフレームワークは、Spring 中心にやっている。

でも、モデル駆動設計やユビキタス言語は、トランザクションスクリプトやテーブルモジュールパターンでも効果的なはず。もちろん、実装フレームワークや開発言語に何を選ぶかとは、関係なく、有効。

モデル駆動設計と、ユビキタス言語が、DDD の基本テクニック。

そして、その根底にあるのは、「ドメインの知識への興味」「ドメインの構造やルールを、発見する面白さ」なんだと思う。

そういう興味や面白さが動機になって開発したソフトウェアは、利用者の役にたつ、喜ばれるソフトウェアになる。

また、ドメインの構造をうまく表現したソフトウェアは、要求の追加も、簡単に、安全にできるようになる。
要求は、ドメインから生まれる。だから、ドメインの構造をうまく表現しておけば、追加の要求も、すんなり、そこに収まる、ということ。

こういう、知的好奇心というか、「わかる面白さ」を、チームのメンバーで共有しながら、仕事をするのは、楽しいものです。

その興味の対象が、技術テーマか、ドメインの課題か、というちょっとした(?)問題はありますが....

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM