6/11に「JJUG ナイトセミナー 6.11 ドメイン駆動設計特集！」に行ってきました。２回に分けてセミナーの内容を紹介します。
【東京】JJUG ナイトセミナー 「6.11 ドメイン駆動設計特集！ 」 - 日本Javaユーザーグループ | Doorkeeper
今回は１回目です。最初のセッションは、グロースエクスパートナーズ株式会社 和智 右桂さんの「「コードに語らせるために」でした。
セッション内容
前置き
- 「エリック・エヴァンスのドメイン駆動設計」（以下DDD本）の第一部を読み返すと著者のメッセージが伝わる
- うまくいかないのは業務が難しいからではないか
- 技術領域には興味がある人が多いが、業務はやりたがらない
DDD本の貨物輸送の業務について
- Amazonのような会社をイメージ
- 船便で、コンテナに詰め込んで、定期便で送る
- 海運輸送のようなイメージ
DDD本の概要
DDDとは
- ドメインとは業務である
- 本を理解する上で役に立つのが参考文献
- 「エンタープライズ アプリケーションアーキテクチャパターン」の影響が濃い
- ファウラーのDSLはDDDの発展形と言えるのではないか
エッセンスは？
- このシステムのことが良く理解できたと思ったのは？
- システムテスト、シナリオテストで「そのような使い方をするのか」と、システムを理解できたことが多い
- 学習とは、顧客の業務を理解すること
- 顧客の言葉で理解すること
- 「ファイルが送信されてきたら、フラグを立てる」では、顧客の言葉ではない
- ユビキタス言語で理解する
再構築とは？
- モデルを共有すること
- わかりやすいのは、手続きとの対比
- システムのリリースを手続き的に教えると、作業者はリリースできるが、ただコマンドを打ち込んでいるだけとなってしまう
- アプリケーションのシステム構成を理解させることがモデルを共有することにあたる
- 顧客の会社に入社した社員に業務を理解させるようなもの
- 再構築の最終ステップ
モデルとソフトウェアがきっちり揃っていると、いいことがたくさんある
- 業務の変化にソフトウェアの変化が追随できる
- 一回きりしか作らないなら必要ないかもしれないが
ユビキタス言語
- チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いる
- 図やドキュメント、会話の中で同一の言語を用いること
- 顧客の使う言葉とコード内の言葉が一致しないのはよくない
- 会話も顧客の言葉で行う
- DDDは顧客との向き合い方とも言える
モデリングパラダイム
- モデルとコードを結び付けるツール
- オブジェクト指向
- モデルとは頭の中にある概念であり、それを表現するツールとしてオブジェクト指向を用いている
イテレーティブなプロセス
- 一回作って終わりではない
- 顧客とのコミュニケーションを通じてモデルは深みを増していく
- 顧客の意識にもなかった概念が出てくることもある
DDD本の読み方
- 以下の順序で読むと理解しやすい
- 第一部、第三部、第四部、第二部
- あるいは、第一部、第三部、第二部、第四部
開発の中のDDD
- 最初に設計して枠組みを作る
- 枠組みにのって、その後を作る
ユースケース分析
構成図と個別の設計
- 機能間の関連の分析および機能ごとの設計
- ここで設定した境界を後から再構築するのは非常に大変
DDDの実践
Domain Language /DDD
DOMAIN LANGUAGE MODEL EXPLORATION PROCESS
- シナリオを顧客から聞くことから始まる
- モデリングをする
- 顧客に見せる
- モデルのリフレッシュ
- make mistakes
- コードに落とす
- 画面設計、データモデル設計はそれとは別に進める
保守でもDDDはできる
- DDDの本質は成長
- フィードバックを受け取りながらモデルは成長していく
- 実践テスト駆動開発の著者はDDDがとても好きな人たち
ドメインモデルのための余地が必要
- 「新規のクラス作成は禁止」のようなルールがあると、DDDは厳しい
- ドメインモデルを少しずつ抽出していく
- DDDはコードの書き方というより思想
- 業務を理解して、ドキュメントに起こしていくことから始めることも価値がある
手続きからモデル駆動へ
複雑な業務
- あらゆる機能で必要というわけではない
- 単純な業務＝データスキーマの操作だけで表現できる業務なら手続で十分
- 例えば、住所変更するだけならDDDはいらない
- 住所変更する際に複雑なルールがある場合はDDDは有用
- 技術面での難易度とは別
- 処理が複雑だからDDDというわけではない
- ドメインエキスパートと会話する必要はない
エンティティの先
- モデルによってとらえられる知識は「名詞を見つける」ことに留まらない
- ビジネスの活動やルールもドメインにとって中心的
- データスキーマの先が重要
- エンティティを超えてその先に行こうとする動きのときに、真価を発揮する
レイヤ化アーキテクチャ重要
- ドメインレイヤを用いて、そこにドメインロジックを集約させる
- ドキュメントも、テストも（ソースコードだけではない）
- 画面ごとに入出力仕様書があるような画面駆動設計だと、ドメインロジックのドキュメントの書き場がなくなる
躓きこそ最大のチャンス
- モデルの抽出がなんだかうまくいかない
- 顧客的には一ヵ所の修正が、あちこちに波及する
- テストケースがうまく洗い出せない
- キモがどこかわかっていない
- モデルがどこか間違っている
参考文献
関連エントリー
「JJUG ナイトセミナー 6.11 ドメイン駆動設計特集！ 」に行ってきた（その２「DDDを実践する時に役に立つ話し」by グリー株式会社 加藤 潤一さん） - プログラマーな日々
セッション資料
コードに語らせるために
