Skip to content

vol1_20140222

Jump to bottom Edit New page
@kuma_nana edited this page Mar 10, 2014 · 13 revisions

第１回ドメイン駆動設計読書会@大阪

目次

概要

読書会の主旨

  • DDDが最高という事ではない。
  • DDDも1つの手法にすぎない。
  • DDDの主義や本質を学ぶ場にしたい。
  • 今までの手法を肯定しながらやっていく
  • 短絡的に結論や答えを求めず、学ぶ過程を楽しむ場にしたい。

読書会の進め方

  • 毎回レポーター担当を用意し、読書会内容やディスカッションを追記していく
  • Git上にDDD読書会のプロジェクトを用意している
  • 全部で第6回で一旦終了する予定。（章としては第5章）
    • 時間内に終わらせることよりもしっかり学ぶことを重視するため、進捗に応じて回数が増えることも。
    • PHPメンターズとしては、DDD本読書会は第5章までをおススメしている

読書会を開催したキッカケ

ナビゲーションマップ

  • 表表紙（紙の書籍だと扉表紙、Kindle版だと第2部の冒頭の方）

    • ドメイン駆動設計はパターン言語の体裁
    • ドメイン駆動設計の中心
      • ユビキタス言語
      • モデル駆動設計

  • 裏表紙（Kindle版だと第14章の冒頭等）

    • 大規模なシステムをどうまとめるかのパターン
    • 同じく、ユビキタス言語とモデル駆動設計
    • 最近は「ドメインイベント」も入ってきている
    • 近年重要性を増してきているのは「コンテキストマップ」

日本語版への序文

  • DDDの原則は3つ

    • コアドメイン
    • モデルの探求
    • ユビキタス言語

  • ここでいうコンテキストとは？

    • ある程度大きなソフトウェアの場合の話
    • 同一パッケージでも違うチームで分担作業する場合に、コンテキストで分割することがある
      • たとえば、ユーザDBの「ユーザ」がどういった属性、振る舞いを持つかは、コンテキストで異なる
      • お互いの情報交換は、オブジェクト間でコンバートする、といった使い方をする
    • 開発者と関係者同士が認識する共通項
    • 概念は同じ意味でも詳しく見ると異なる事がある

  • 「リスクもある程度受け入れなければならない」で書かれているリスクとは？

    • 自分の思い通りいかない事があるというリスクの事と思われる
    • 忍耐が重要

日本語版推薦文

  • 推薦文にはエリートプログラマー達の本の感想・見方などが濃縮されている

  • 読み飛ばすのはもったい無い

  • 榊原　彰さん

    • ドメイン知識
      • ユーザの関心が寄せられている知識の体系
        • 『新装版 マルチパラダイムデザイン』ピアソン桐原、2009より
      • 分析するビジネスを構成する知識
      • 何をモデル化しようとしているかというと、「ドメイン知識」
        • プロセス、エンティティ、制約、他の知識体系
        • モデリングによってそれを見つけ出していく
      • ドメイン知識をアプリケーションに活かすことについて（そして言語ワークベンチ）の先駆者であるIntentional SoftwareのWebサイトではナレッジと呼ばれている
      • 顧客も気づいていないかもしれないが、確かにそこに存在している

  • 羽生田栄一さん

    • DDDが活用される土壌が整ってきた
    • DDDは他手法にも活用される。親和性が高い。
      • DSL設計、James O. Coplien氏の問題ドメイン分析等

  • 平鍋健児さん

    • ユビキタス言語はXPでいうと、メタファーのプラクティス

序文

  • ドメインの根底に存在する構造（ドメイン知識）を導入
    • モデリング
    • モデリングの足がかりとして、佐藤正美氏のTMにおける管理過程を対象とするのがよいかもしれない
      • 事業過程とは、実際に営まれている事業のことをいう。管理過程とは、事業過程を管理するために導入された報告過程である。したがって、管理過程は、事業過程に対する 1つの モデル （情報体系） である、と云ってもよい。 ー http://www.sdi-net.co.jp/blackbook-05.htm
    • IT勉強宴会の帳簿組織に関するスレッドも参照のこと。
  • 人が変わってもデータは変わらない
  • 第28回関西IT勉強宴会での資料がいいかも

Casual Talk

  • 「イベント告知サイトをモデリングしてみる」

  • 発表者:@kuma_nanaさん

  • ドメインとは？

    • 活動やシステム化したい対象の領域
    • モデル：対象を認識した形に組み立てるもの

  • モデリング作業

    • Activityをいかにとるか、そこに知識体系を設定していく
    • ドメインを使って、再利用できるプログラミングをやってみたい

全体のまとめやディスカッション

  • コンテキストマップとは？

    • 見る人の立ち位置
    • コンテキストをベースに閉じた世界で作業をする

  • Web開発の場合

    • エンドユーザは遠いけれども、ドメインエキスパートとは一緒のチームとして仕事をしているので、DDDを適合しやすい

  • ユビキタス言語

    • 設計と実装の間でユビキタス言語を作っていくアプローチも良いのでは
    • 開発者とコンサルタントとの間で作るユビキタス言語にも価値があるのでは

  • ウォーターフォールでもDDDって出来るの？

    • 出来ないことは無いと思うが、アジャイルとの親和性が高いのは確か
    • フィードバックを如何に受け取るループが作れるかが大切
    • ドメインエキスパートが遠いと難しいですよね

  • プログラマーとインフラエンジニアが「Ｃｈｅｆ」共通項として、認識共有したりしている

  • DSLが流行る世界は、顧客自身がアプリ開発できるから価値が高いよね

    • でも、ＳＩｅｒの仕事形態は変わるよね。少なくとも、今のままでは生き残れないよね。

  • チームでの解決するときにDDDを使われることが多い？

    • DDDにこだわる必要はまったくない

  • エリック以外のDDD流派はあるの？

    • 基本的には無い

  • 会社でDDDやってみた

    • 付箋で解決したい事を張り出してみた
    • 問題とするレベル(粒度)がメンバー内でもバラバラな事が分かった
    • 解決ドメインがあるのなら、そこから模倣してみては。
    • スターターセットが使えるかも
    • みんながDDD初心者だと難しいよね

  • 管理できるデータから、DDDを行うキッカケというのが新鮮でした

  • 問題に対して社内で話し合うというのが無かったからよかった

  • ユビキタス言語がわかりやすいけど、PHPメンターズではユビキタス言語とモデル駆動設計と考えている

  • 世界的にDDDが流行りだしている

  • Martin Fowler氏のいうところの 信じられないほどの価値をもたらし得る ドメインモデルを1度でも作りたい。それはドメインエキスパートに新たな見方を与えるような、問題ドメインに影響を与えるようなものである。

  • 業務的に「新しいこと」というのはほとんどなくて、9割は過去にもう誰かによって取り組まれ、体系化されている。既存の例を探すことは有用。

  • 平鍋健児さんによる InfoQ の記事

  • 問題ドメインと解決ドメイン

    • 問題ドメイン：ユーザの知識、プロセス、エンティティ、制約
    • 解決ドメイン：アーキテクチャ、基本コンポーネント

  • モデルの一例

  • 言語ワークベンチ

  • 語彙

雑談

  • DDD本にはエリックの青本の他に、もう一冊Red本があるらしい

  • IT本を読むときのコツ

    • 本の冒頭にある、謝辞や紹介文を飛ばさない
    • そこには、達人たちが本を読んだ時の感想やエッセンスが書かれている
    • 本を読む上で手助けになる事も書かれているので、読み飛ばすのは勿体ない

タイムスケジュール実績

14:30 開場
15:00-17:00 スタート、趣旨説明、自己紹介、読書会、休憩
17:00-17:45くらい？ カジュアルトーク、撤収
スペース利用時間  3時間超

感想ブログリンク集

Add a custom footer
Add a custom sidebar
Clone this wiki locally