かまずにまるのみ。

文鳥とかビールとか

DDD体験ワークショップに参加してきました

PHPカンファレンス2013PHPメンターズ さんの『モデルとの向き合い方:ドメイン駆動設計体験ワークショップ』に参加してきました。
PHP メンターズさんの記事と資料はこちらに掲載されています。
http://phpmentors.jp/post/61286646859/phpcon2013-ddd-workshop


ドメイン駆動設計って?

そもそもドメイン駆動設計とは何なのか。

ドメイン駆動設計(DDD)はビジネスドメインの概念をソフトウェアという人工物にマッピングすることです。

ドメイン駆動設計・開発の実践

上記引用元にも出ている Eric Evans 氏の書籍は 「エリック・エヴァンスのドメイン駆動設計」というタイトルで日本語版が出版されています。(この書籍については以降 DDD 本と表記)
500ページ超とそこそこボリュームはありますが、読みやすい本だと思います。
気になっているけど躊躇しているという方は書店で手にとってみるのをおすすめ。

f:id:tdakak:20130917161153p:plain:w250


ワークショップ振り返り

以下、手元にある DDD 本と当日のメモでスライドを補完しつつ、ワークショップを振り返った記録。

ドメイン駆動設計は哲学である

スライド - DDD 基礎 - 何であって、何でないか にもある通り DDD とは哲学です。
具体的な手順や実装、プロセスについて語るとき、その哲学や思想も一緒に理解することはとても大事なことだと思います。
また、DDD 本にはこの哲学を議論するための語彙としての役割があります。
哲学、思想を共有するための用語集ですね。


ユビキタス言語とモデル駆動設計

スライド - DDD を俯瞰する - 最重要パターン にはユビキタス言語モデル駆動設計が挙げられています。
これらの用語について DDD 本には以下のように書かれています。

ユビキタス言語(UBIQUITOUS LANGUAGE)
ドメインモデルを取り巻いて構築され、チームのあらゆる活動をソフトウェアと結びつけるために、チームメンバ全員によって使用される言語。

モデル駆動設計(MODEL-DRIVEN DESIGN)
ソフトウェア要素のサブセットがモデル要素と密接に対応している設計。また、相互に一致した状態を保ちながら、モデルと実装を共に開発するプロセス。

 

モデリングとは?

モデル駆動設計の「モデル」というのは一体何なのか。
これは スライド - モデリングとは? で説明されています。

モデルの説明を読んでいると概念とか抽象化とか出てるけど、じゃあモデリングと設計って何が違うの?という疑問も出てきますが、それは スライド - モデリングと設計の違い に書かれている通り。
モデリングは設計書作成の手がかりなんですね。
イテレーションをぐるぐる回していくうちにこれらは洗練されていきます。

f:id:tdakak:20130917163351p:plain


実際にやってみよう

スライド - ワークショップ - 流れ

  1. 要件を聞いて
  2. そこからユビキタス言語を抜き出し
  3. モデリングして
  4. ユースケース作成

 

ドメイン辞書をつくる

要件からユビキタス言語を抜き出し、ユビキタス言語をまとめた辞書(ドメイン辞書)を作成します。
辞書作成時に留意する点は スライド - ドメイン辞書 にまとめられています。
スライド - ドメイン辞書(2) にあるのはドメイン辞書の一例です。
あくまで一例であって、唯一の答えではありません。(くどいけど大事なことなので二回書いとく)


ドメインモデルを表現する

ドメイン辞書を作成したら、次は スライド - ドメインモデル を参考にモデリングしてみます。
最初からがっちりしたものを作る必要はなく、 略式 UMLUML っぽいもの)や付箋紙 CRC から始めるそうです。今回は略式 UML でやってみます。

ここで表現するのはあくまで概念であって、実装ではないです。
要件を聞くとつい「こーいうテーブルを作成して…」とか「あーいうページ遷移で…」とか具体的な実装が頭をよぎりがちですが、ここではいったん忘れます。
大事なのは概念を抽象化して表現することです。

下記は略式 UML によるドメインモデルの一例です。
一例であって正解では(以下略

f:id:tdakak:20130917165138p:plain:w400

ユースケースを考える

ユビキタス言語、ドメインモデルを作成したら次はこれらの検証を行います。
スライド - ユースケース
ユースケース作成の際、スライド - ユースケースのレイヤー にも注意します。
ドメインユースケースではサービスが起点となり、主語がサービスになります。

ユースケースを考えたときにドメインモデルに違和感を覚えることもあるかもしれないですし、ドメインモデルを作成する段階でユビキタス言語に不足を感じることがあるかもしれません。
気になった点などを確認しながら、ドメイン辞書(ユビキタス言語)→ドメインモデル→ユースケース→ドメイン辞書…とぐるぐる回していきます。


体験してみて

f:id:tdakak:20130918135432p:plain

DDD 本を読んでいるだけだといまいち「実際どうやって適用するか」というところがピンと来なかったのですが、今回体験してみてこの辺りが少し見えてきたように思いました。
足踏み状態から一歩前に踏み出せた気がしています。

あと、参加して改めて感じたのが PHP メンターズさんのメンター力の高さ。
参加前は何も分かっていないふわふわな状態でも、参加後には何かを得たと思えるような。
Symfony 勉強会のときもそうだったのですが、導入としてまず「哲学や思想を共有する」という方法は素敵だなーと思っています。

ワークショップには参加できなかったけど DDD に興味がある方、スライドを見ながらぜひ実際に手を動かしてみてください。


PHPカンファレンスのこと

PHP カンファレンスは昨年に続いて2回目の参加。
今回もとても充実した楽しい時間を過ごすことができました。
数百人の方が訪れるとても大きい規模のイベントですが、進行も非常にスムーズで大きな問題もなく素晴らしいイベントでした。
スタッフの皆様、スピーカー・ワークショップ担当の皆様、本当にありがとうございました!


2013/09/18 14:28 追記:

「体験してみて」に表示していた画像を修正しました。
修正前の画像には「哲学だけではご飯は食べられない」というネガティブな表現が含まれていて、「DDD は哲学 → 哲学はご飯食べられない → DDD は役に立たない?」と誤解されかねない表現でしたので少し補足します。

まとめで言いたかったことを3行でまとめると以下になります。

  • 哲学だけでは解決できない問題が多々ある
  • 哲学を実際の現場なりシステムなりに適用するための、具体的な方法が欲しい
  • 今回 DDD でその方法を知ることができてよかった!

今回 DDD 体験ワークショップを通して、DDD の哲学を具体的な手段に落とし込むためのひとつの方法が得られたように思っています。
哲学を手がかりにしてどのように問題を解決していくか。
哲学を元にどのような手段、プロセスを作っていくのか。

なので最終的な答えとしては「DDD は現場で使えるもの(ご飯が食べられる!)」です。