19-B-5 パネルディスカッション 出張！ DDD難民救済キャンプ 〜ドメイン駆動設計をあきらめない〜／和田卓人,角田直行,和智右桂,佐藤匡剛,渡邉健太郎

devsumi2010

会場の他の人はどうかしらないんですけど、私は DDD という本も言葉も全然しりませんでした。聞いてみたのは和田さんの名前があったからです。
パネルは面白かったです。でもあまりにも難民というので、DDD を読もうという気にはなりませんでした(^^;
最後の締めはなんだったんでしょうか(^^;

以下適当なメモ。嘘かいてあるかもしれません。

和田さん

  • 会場に質問。DDDを読みきった人→一人
  • ぶ厚さに挫折して難民多数
  • パネラーは読みきった人たち エベレス登頂した人たち
  • TDD はいいんだけど、ソフトウェアの内面の美しさをどうするか

角田さん

  • DDD読書会を行ってきた。
  • DDDには冷やかな目を持ってる
  • 本当に実践できるの？という人の立場で

渡辺さん

  • 残念な設計のシステムにであって、もうちょっとよりよいアプローチがないか
  • 改善の希望が DDD
  • 現場の人に取っての DDD の良いところとか

和智さん

佐藤さん

なぜ今DDDか

角田さん

  • 日本でDDDはまだ流行ってない
  • 海外ではDDDが流行ってる
  • Yahoo! Groups 2009年に飛躍的に投稿数がのびている
  • 仮説
  • ドメインモデル貧血症
  • RDBMS自身が持つ高度な機能のためにまかせすぎちゃって、トランザクションスクリプトパターンになってしまっている
  • 業務処理をドメインを実装すべきところなのに
  • Google App Engine とか Azure とか NoSQL とか流行ってる
  • SQL とかストアドプロシジャじゃなくて、アプリケーション側で業務処理を実装することが増えて行くのではないか。より健全な方向に向かうんじゃないか。
  • Struts, Rails とか便利なフレームワークが成熟
  • ドメインを扱うフレームワークが見当たらない
  • 金融の計算処理とか物流のフローはやってくれない
  • The Heart of Software
  • ソフトウェアの核心の中にある複雑さに立ち向かう
  • ユーザーのドメインに関連した問題を解決する能力
  • DDD ではドメインがもっとも重要
  • 問題領域を把握する
  • 特定のプログラム言語とかフレームワークとかデザインパターンとかに注目しがちだけど、もっとドメインに注目すべき
  • 今海外ではやってるのはそういう理由では。

The Book

佐藤さん

  • 「Domain-Driven DESIGN」
  • ドメイン駆動設計
  • ドメイン＝「知識、組織、活動の領域」
  • 知識 ビジネスルールや業務知識
  • 組織 権限とか
  • 活動 製造や流通のプロセス
  • アプリケーションの核
  • 「複雑なドメインは、モデルに基づいて設計すべきだ」
  • ドメインモデルに基づいてソフトウェアを設計する
  • ドメインモデル＝実装パターンではない
  • 抽象的なモデルを作る必要がある
  • 「有能はドメインモデラーは、知識の噛み砕きをしている」
  • ユビキタス言語
  • ユーザーやドメインエキスパートと対話するときにユーザーの言葉で作られたドメインモデルをベースに会話をしていこう
  • ユーザーとの会話だけで終わってはダメなので、プロジェクト全体に広げる
  • これがDDDの真髄
  • モデル駆動設計 Model-Driven Design
  • UMAを書くと実装がつくられる…というものではなく、実装からモデルにフィードバックもある
  • ビルディングブロック
  • 深いモデル
  • これで終わりではない
  • 重要なのは1回作って終わりではない。ドメインもデルをインクリメンタルに洗練させていく
  • ドメインリファクタリング
  • ドメインを深く反映させた深いモデルをつくろう
  • ブレイクスルーという境地がある
  • そこまで目指す

自分にとってのDDD

佐藤さん

  • DDDこそがソフトウェア開発が目指すべき最終形
  • テクノロジーはどんどんかわるが
  • 人間が扱うモデルは 100年200年たってもかわらない
  • 衣食足りて礼節をしる
  • これこそが人間の最終形

角田さん

  • DDD自体はいいものだけど、そんな手放しではよろこべない
  • DDDは開発の生産性を高めるものではない
  • むしろ長くなる
  • モデルをディープにしたりブレイクスルーがおとずれるまで練ってると、開発の納期に間に合わない
  • すべてに適応できるわけではない
  • 「90%はDDDに適応しない」
  • Rails で1,2週間で納品できるようなプロジェクトに採用しても意味はない
  • 全部に適用しようとするのは危険

渡辺さん

  • 長期的に見ると徐々に改善していくのでは。適材適所
  • 10:90で大半は90。単能機でガッと作るのはOK
  • 残り10のプロジェクトは 10回に1回はある
  • 10のプロジェクトに90のやり方を適用するのはまずい
  • 判断するために自分の中にアプローチをもっておく必要がある

和智さん

  • DDDの難しさ
  • 全部DDDの思想から実践までフルスタックでやる必要はない
  • ドメインモデルは初めからあるものではない
  • 一つはドメインモデルを表す言葉を見つける
  • 言葉をコードまで落とし込む
  • 同じ言葉で、同じものをみる
  • 新しい言葉を見つけることで見えていなかったものが見えてくる

明日から始めるDDD

角田さん

佐藤さん

  • パターンの紹介によりすぎちゃってるので注意

渡辺さん

  • 「Domain-Driven Design Quickly 日本語版」http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
  • InfoQ Japan からダウンロードできる
  • 「ドメイン駆動」翔泳社
  • DDDの翻訳ではない
  • 開発者としては概念じゃなくて実装が気になる
  • 実装よりのことが知りたい人にはいい
  • イメージがつきやすい

佐藤さん

  • 翔泳社さん The Book の翻訳本だして

実装者向け

和智さん

  • プラクティス
  • Daoをレポジトリという名前にかえてみるとかwww

渡辺さん

  • ドメインモデル
  • 業務の概念を表しているものを扱わないといけない

佐藤さん

渡辺さん

  • 名前を変えるのが見方を変えるというのなら、それもあり

佐藤さん

  • 実装者がドメインモデルのことを考える意識つけになるのでは

渡辺さん

  • 結合表に新しい名前をつけるのはレポジトリっぽくない

角田さん

設計者向け

佐藤さん

  • Excelで設計したらおわりではなくて実装を考えて設計する

和智さん

  • 設計者と実装者は近い立場

角田さん

  • 「プログラムできないから設計者になろう」という人はむずかしい
  • コードレビュー
  • クラスとかメソッドとかユビキタス言語になってるか設計者の視点でコードレビューする

佐藤さん

渡辺さん

  • ユビキタス言語レビューやろうと言うとハブられる
  • 用語集は捨てられていく
  • それをちゃんと実装レベルまで徹底していく

角田さん

  • ちゃんとユビキタス言語が使われてるかをチェックする

佐藤さん

  • みなさんもぜひ

和智さん

  • すでにドメインモデルがあってユビキタス言語があるんじゃなくて、今から作っていくという場合は、ユビキタス言語を考慮して設計する

マネージャ向け

渡辺

  • マネージャはある程度の規模のプロジェクトだとチーム編成が大きくなる
  • チームを組むとき業務のまとまりでチームを作る
  • DDDでいうと高次の設計判断 戦略的設計
  • ドメインの観点からどういう風にチームを割ればうまくいくか
  • 出てきたものをひたすらうけいれるというパターンもある
  • うまく使えばチーム設計をうまくできるかも

佐藤さん

  • 優秀な人は共通基盤チームにわりあてられがち
  • アプリケーションエンジニアの復権
  • 優秀な人を業務ロジックにわりあてる

渡辺さん

  • インフラが成熟してきたんなら、ドメインに力を

角田さん

  • 実装者に設計者よりのことをお願いしてみる。逆も
  • 勉強会してみるのもいい

和智さん

  • ハンズオンモデル
  • 実装考えながら設計する
  • 実装しながらドメインのことを考える
  • マネージャにはそういうキャリアパスも考えてほしい

終わりに

角田さん

Domain-Driven Design: Tackling Complexity in the Heart of Software

Domain-Driven Design: Tackling Complexity in the Heart of Software


ドメイン駆動 (Programmer’s SELECTION)

ドメイン駆動 (Programmer’s SELECTION)