DDD体験ワークショップに参加してきました
PHPカンファレンス2013 で PHPメンターズ さんの『モデルとの向き合い方：ドメイン駆動設計体験ワークショップ』に参加してきました。
PHP メンターズさんの記事と資料はこちらに掲載されています。
http://phpmentors.jp/post/61286646859/phpcon2013-ddd-workshop
ドメイン駆動設計って？
そもそもドメイン駆動設計とは何なのか。
ドメイン駆動設計（DDD）はビジネスドメインの概念をソフトウェアという人工物にマッピングすることです。
ドメイン駆動設計・開発の実践
上記引用元にも出ている Eric Evans 氏の書籍は 「エリック・エヴァンスのドメイン駆動設計」というタイトルで日本語版が出版されています。（この書籍については以降 DDD 本と表記）
500ページ超とそこそこボリュームはありますが、読みやすい本だと思います。
気になっているけど躊躇しているという方は書店で手にとってみるのをおすすめ。
ワークショップ振り返り
以下、手元にある DDD 本と当日のメモでスライドを補完しつつ、ワークショップを振り返った記録。
ドメイン駆動設計は哲学である
スライド - DDD 基礎 - 何であって、何でないか にもある通り DDD とは哲学です。
具体的な手順や実装、プロセスについて語るとき、その哲学や思想も一緒に理解することはとても大事なことだと思います。
また、DDD 本にはこの哲学を議論するための語彙としての役割があります。
哲学、思想を共有するための用語集ですね。
ユビキタス言語とモデル駆動設計
スライド - DDD を俯瞰する - 最重要パターン にはユビキタス言語とモデル駆動設計が挙げられています。
これらの用語について DDD 本には以下のように書かれています。
ユビキタス言語（UBIQUITOUS LANGUAGE）
ドメインモデルを取り巻いて構築され、チームのあらゆる活動をソフトウェアと結びつけるために、チームメンバ全員によって使用される言語。
モデル駆動設計（MODEL-DRIVEN DESIGN）
ソフトウェア要素のサブセットがモデル要素と密接に対応している設計。また、相互に一致した状態を保ちながら、モデルと実装を共に開発するプロセス。
モデリングとは？
モデル駆動設計の「モデル」というのは一体何なのか。
これは スライド - モデリングとは？ で説明されています。
モデルの説明を読んでいると概念とか抽象化とか出てるけど、じゃあモデリングと設計って何が違うの？という疑問も出てきますが、それは スライド - モデリングと設計の違い に書かれている通り。
モデリングは設計書作成の手がかりなんですね。
イテレーションをぐるぐる回していくうちにこれらは洗練されていきます。
ドメイン辞書をつくる
要件からユビキタス言語を抜き出し、ユビキタス言語をまとめた辞書（ドメイン辞書）を作成します。
辞書作成時に留意する点は スライド - ドメイン辞書 にまとめられています。
スライド - ドメイン辞書(2) にあるのはドメイン辞書の一例です。
あくまで一例であって、唯一の答えではありません。（くどいけど大事なことなので二回書いとく）
ドメインモデルを表現する
ドメイン辞書を作成したら、次は スライド - ドメインモデル を参考にモデリングしてみます。
最初からがっちりしたものを作る必要はなく、 略式 UML（UML っぽいもの）や付箋紙 CRC から始めるそうです。今回は略式 UML でやってみます。
ここで表現するのはあくまで概念であって、実装ではないです。
要件を聞くとつい「こーいうテーブルを作成して…」とか「あーいうページ遷移で…」とか具体的な実装が頭をよぎりがちですが、ここではいったん忘れます。
大事なのは概念を抽象化して表現することです。
下記は略式 UML によるドメインモデルの一例です。
一例であって正解では（以下略
ユースケースを考える
ユビキタス言語、ドメインモデルを作成したら次はこれらの検証を行います。
スライド - ユースケース
ユースケース作成の際、スライド - ユースケースのレイヤー にも注意します。
ドメインユースケースではサービスが起点となり、主語がサービスになります。
ユースケースを考えたときにドメインモデルに違和感を覚えることもあるかもしれないですし、ドメインモデルを作成する段階でユビキタス言語に不足を感じることがあるかもしれません。
気になった点などを確認しながら、ドメイン辞書（ユビキタス言語）→ドメインモデル→ユースケース→ドメイン辞書…とぐるぐる回していきます。
体験してみて
DDD 本を読んでいるだけだといまいち「実際どうやって適用するか」というところがピンと来なかったのですが、今回体験してみてこの辺りが少し見えてきたように思いました。
足踏み状態から一歩前に踏み出せた気がしています。
あと、参加して改めて感じたのが PHP メンターズさんのメンター力の高さ。
参加前は何も分かっていないふわふわな状態でも、参加後には何かを得たと思えるような。
Symfony 勉強会のときもそうだったのですが、導入としてまず「哲学や思想を共有する」という方法は素敵だなーと思っています。
ワークショップには参加できなかったけど DDD に興味がある方、スライドを見ながらぜひ実際に手を動かしてみてください。
PHPカンファレンスのこと
PHP カンファレンスは昨年に続いて2回目の参加。
今回もとても充実した楽しい時間を過ごすことができました。
数百人の方が訪れるとても大きい規模のイベントですが、進行も非常にスムーズで大きな問題もなく素晴らしいイベントでした。
スタッフの皆様、スピーカー・ワークショップ担当の皆様、本当にありがとうございました！
2013/09/18 14:28 追記：
「体験してみて」に表示していた画像を修正しました。
修正前の画像には「哲学だけではご飯は食べられない」というネガティブな表現が含まれていて、「DDD は哲学 → 哲学はご飯食べられない → DDD は役に立たない？」と誤解されかねない表現でしたので少し補足します。
まとめで言いたかったことを3行でまとめると以下になります。
- 哲学だけでは解決できない問題が多々ある
- 哲学を実際の現場なりシステムなりに適用するための、具体的な方法が欲しい
- 今回 DDD でその方法を知ることができてよかった！
今回 DDD 体験ワークショップを通して、DDD の哲学を具体的な手段に落とし込むためのひとつの方法が得られたように思っています。
哲学を手がかりにしてどのように問題を解決していくか。
哲学を元にどのような手段、プロセスを作っていくのか。
なので最終的な答えとしては「DDD は現場で使えるもの（ご飯が食べられる！）」です。
ゆるかわPHPの会#2 参加しました
2013/07/06 に行われた ゆるかわPHPの会#2 に参加しました。
場所は恵比寿にある 株式会社 Engine Yard さん。
発表されたテーマは環境構築、テストから同時実行制御まで幅広い感じ。
言語などに捕われず、ゆるさを許容してくれるゆるかわ PHP。
ロックについては改めて考えるいい機会になりました。
当日発表されたスライドは主催の @polidog さんのブログにまとめられています。
ゆるかわPHP#2を開催しました | polidog lab++
自分の発表は前回に引き続き PHP とは直接関係ないものでした。
主旨がぶれてしまったのが心のこり。
発表の後はワールドカフェっぽい感じの雑談タイムに。
短い時間でしたがいろいろな立場や経験を持った人、自分と異なる視点や考えの人とお話できて楽しかったです。
初めてカフェオーナーっぽいことをやったけど話題振ったりまとめたりするの難しい。こみゅにけーしょんりょくぶそくをつうかんしてつらい。
でも機会があればまたやってみたいです。
最後に参加者の皆さん、主催の @polidog さん、会場を提供してくださった Engine Yard さんありがとうございました！
次回開催を楽しみにしています。
アジャイル設計と5つの原則
アジャイルソフトウェア開発の奥義 第2部「アジャイル設計」の自分用まとめ。
アジャイル設計
アジャイルな設計
「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。
悪い設計
第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。
- 硬さ （設計変更が難しい）
- 脆さ （設計が壊れやすい）
- 移植性のなさ （再利用が難しい）
- 扱いにくさ（正しい設計をするのが困難なソフトウェア、面倒な開発環境）
- 不必要な複雑さ（"後で必要になるかもしれない"と考えて先行実装したコード）
- 不必要な繰り返し （コピペ）
- 不透明さ （目的や意図がわかりにくい）
原則
システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。
ただし無条件で原則に従うと「不必要な複雑さ」を招くこともあるので注意。
- 単一責任の原則 (SRP : Single Responsibility Principle)
- オープン・クローズドの原則 (OCP : Open-Closed Principle)
- リスコフの置換原則 (LSP : Liskov Substitution Principle)
- 依存性逆転の原則 (DIP : Dependency Inversion Principle)
- インタフェース分離の原則 (ISP : Interface Segregation Principle)
