『DDD（ドメイン駆動設計）をやってみよう」に参加してきた

勉強会 DDD


(写真：会場へ向かう途中にそびえ立つ中野サンプラザ。)

DDD(ドメイン駆動設計)に関しては、過去に1度、下記の勉強会に参加して以来となります。DDD本については興味を持っていたものの、敷居の高さ(？)に書籍購入を躊躇ってしまい、以降そのまま･･･という感じでした。そんな感じで今回の勉強会に参加です。

今回勉強会を主催された会場では、主に『B面』なテーマや技術について勉強会を行うことが多く、当初は『DDD』もB面に属していたそうです(笑)

DDDについてはその際に(B面のうちに)やるつもりではいたものの、DDDの翻訳本が出たり震災があったりやらで延び延びになってしまい、すっかり『A面』感満載となった現在に至り、実施の運びとなったようです。

ドメイン駆動設計（DDD）をやってみよう


  • ドメインモデルとは？
    • 利用者(利害関係者)の関心事の模型
      • ※関心事でない事がドメインモデルに入ってくることは有り得ない。
    • 利用者の関心事の実装
      • ※実体はコードで実装。
  • DDD こだわりポイント
    • ドメインモデル：利用者の関心事の模型
      • この設計・実装を開発の中心にする
      • 最も優秀なエンジニアが最もパワーを注げるように
    • 設計駆動開発
      • 原則：設計してからコード
      • もうひとつのDDD：Design-Driven Development
      • ※設計とコードは明らかに違う、という教え方（新人など）
    • モデル駆動設計
      • Model-Driven Design / 言葉と絵で、関心事の模型を作って設計・実装
    • Evolve：少しずつ、継続的に成長
      • iterate（反復）/increment（増分）/continuous（絶え間なく）
      • ※ビジネスの要請に合わせたIT側の取り組み。
      • ※特許庁問題：役所ってのはやってみて改善するっていう体質ゼロ。そういう所には合わない。
      • ※ビジネス的に継続的に変化して成長していく、という場合には合う。
      • ※DDDもそういう分野向けの開発には合うのでは無いだろうか。
  • 華麗で楽しい？
    • シングル xDD
      • ケントベックがやるならこういうのは（例：テスト駆動）は美しいと思う
      • でも、リアルのプロジェクトでは･･･？
    • 悪路走破には、四輪駆動
      • マルチ xDD
      • 多くのプロジェクトがこっちなのでは
      • 複数の駆動を上手く組み合わせて進む
    • より速く、より効果的に
  • DDD的8輪駆動(図が見えなかったので割愛w)
  • ドメイン駆動設計を実践すると
    • 利用者の要求のキャッチ力が高まり
    • 利用者の関心事の構造が見えてくる
    • 要件の追加や変更が簡単で安全になる
      • 6〜7割、理不尽な事が無くなった（気がする）
  • DDDはソフトウェア設計
    • 設計原則：関心の分離
      • SRP：単一責任原則
      • カプセルか、情報隠蔽
      • モジュール化（凝集）
      • ：
      • 設計原則：協調
      • 疎結合：必要最小限の結合関係
      • モジュール化（公開インタフェースの最小化）
      • ：
    • ※設計原則をドメインモデルの設計・実装で実践する
    • 全体：有用でシンプルな設計が必要
    • 部品：関心事の分離、違っていたら部品に分ける
      • 単機能なものをたくさん
      • 管理するのは全体側の内部設計で対応
      • 部品をどんな構造でまとめておくか
      • コントローラ役の役割
      • コントロールするのか、委譲するのか（委譲設計）
        • ここのレベルを上げて行かないとコントローラに処理が集中し、見通しが悪くなる

ドメイン駆動設計：スタートアップ / 準備とトライアル

  • 実践シナリオ
    • 利用者の関心事の置き場所を作る
    • 利用者の関心事を見つける
    • 利用者の関心事をコードにしてみる
    • 利用者の関心事の妥当性を検証する(ユーザにとって価値のある検証を)
    • 利用者の関心事の改善点を発見する
    • ※まずは、このサイクルを1回、回せるかどうか。ハードルは高い。
  • 関心の分離（１）
    • 画面
    • UIコントローラ
    • DBアクセス
    • メール送信
    • メッセージング
  • 置き場所の追加：[利用者の関心事を記述するクラス群]を利用する。
    • 画面→→→→→→→→↓
    • UIコントローラ→→→↓
    • DBアクセス→→→→→→→→[利用者の関心事を記述するクラス群]
    • メール送信→→→→→↑
    • メッセージング→→→↑
    • 関心事だけを扱うものを切り出す
    • ドメインクラスの変更があって
    • ※誰から使われているか知らないようにする
      • import文をgrepしてみる。入っていたら相当怪しい（ユーティリティ群を除く）
  • 利用者の関心事クラス
  • 顧客登録サービス<>が各要素を利用。あくまでも利用者から見た時のイメージ。
    • 顧客<>
    • 顧客リポジトリ<>
    • 顧客トランスファー<>
  • 私達が使っている実装技術(注：発表者の環境はJava/Springに特化したもので進めています。)
    • [画面] Velocityテンプレート / Spring Bind, Bean Validation
    • [UIコントローラ] SpringMVC / Spring Web Flow
    • [DBアクセス] SpringORM / myBatis, SQLMap
    • [メール送信] Spring Mail / Apache James
    • [メッセージング] Spring JMS / Apache MQ, MuleESB
    • ※SpringFrameworkには、DDDを漁っていて辿り着いた。
    • ロッドジョンソン『Springの方で全部用意するから･･･」
  • DDD最初の一歩
    • とりあえず置き場を作って、ここにドメインクラスを作ってUIクラスやコントローラクラスから利用してみる
    • 最低一つ、クラスを作る
    • 最低一つ、setter/getter以外のメソッドを作る
    • 顧客の言葉／業務要件を手がかりに
      • サブパッケージ追加/クラス追加/フィールド追加/メソッド追加
    • ごちゃごちゃしてくるので整理整頓を繰り返す
      • 名前の変更/クラスの移動/フィールドの移動/メソッドの移動
  • スタートアップ
    • まずはやってみる
    • つまずく
    • 本を漁る
      • （本来『クライアントと話す』だが、個人的には）
      • →：対象業務のハンドブックや入門書が良い。
      • 英語本は、ドメインモデルの パッケージ名/クラス名/メソッド名 の宝庫。
    • 試してみる
    • 工夫してみる

ドメイン駆動設計　ブラッシュアップ（１）リファクタリング（設計の改善）

  • 業務の関心事の聞知
    • ＜注文入力画面オブジェクト＞データ
      • 業務知識がUIのコードに埋もれている
      • 画面オブジェクトから業務の関心事情報を抽出
      • コントローラから業務ロジックを抽出
      • 業務ロジックをドメインオブジェクトに移動
      • 業務の関心事だけ取り出して、別クラスにする
  • 手続き型の設計（手続き＋データ）をドメインオブジェクトにリフォーム
    • 業務のロジックは情報の近くに移動する
    • 業務データと業務ルールをまとめる
  • 条件記述から業務ロジックを抽出
    • クラス設計に業務の記述を増やす
  • コレクションのカプセル化
    • 技術的な関心→業務の関心
    • 業務でやりたい事をメソッドで表現
  • 単なる値をドメインオブジェクトに昇格する

ドメイン駆動設計　ブラッシュアップ（２）設計のヒント、パターンの利用

  • ドメインモデル設計パターン
    • 業務ドメインに良く出てくる設計パターン
      • 用語や概念
      • 何が関心事か？
      • どう設計するか？
    • パターン集の目次
      • さまざまな関心事を俯瞰する全体マップ
      • アイデアとしては良い。
      • アナリシスパターンは良書だが、実際に内容を実装に適用した事は無い･･･
      • 目次の順番＝業務の関心事の順番、と思って貰ってもよいだろう。良書である。
    • パターン＝設計のヒント
      • 関心の分離のしかた
      • 協調のさせ方
  • Value Object
    • 基本語彙の設計・実装パターン
    • String, BigDecimal, Date/longのラッパー
    • 型宣言→表現力の向上
      • 氏名、社名･･･
      • 金額、数量、日数・・・
      • 登録日、締切日・・・
  • 不変→振る舞いの安定
    • パラメータ付コンストラクタで生成
    • setメソッド禁止
    • 演算結果は、新たにオブジェクトを生成して返す
      • Stringと同じ

  • 6つの役割で考える
    • 情報保持
    • サービス（演算）提供
    • 外部への見せ方
    • 部品群の構造化
    • 制御役
    • 調整役

  • 識別にフォーカスしたクラス
    • 識別番号（参照番号）
      • 発番方法
      • 一意性確保／検証
    • 認証
      • 番号と実体の照合方法、記録
    • 識別名
      • 氏名、品名
      • ：

…とここで、突如増田さんのPCのバッテリーが切れ、スライドが見れない状態に。この後は口頭ベースで進めて行きました。アドバンス編は聞き取れた内容のみメモ。

アドバンス編

  • 隣接ドメインと領域の重なり
    • 受注発注、注文
  • 状態遷移
    • ビジネスルールの宝庫。
    • ステートマシンと状態遷移表を使えば安定したものは作れる。
    • モデルを作ってお客様からフィードバックを得る点において、この分野は非常に難しい。
  • イベント送信
  • あいまい検索、表記のゆらぎを検索
  • データが時系列に溜まった時に、どうやってそれらを扱うか、推定するか


最後に幾つかの質疑応答が行われて、本編終了。

実例(サンプル)を交えての解説が多目だったのでとても分かり易かったですね。ただ今回の増田氏を以てしても悩ましい部分もやはりあるようで(詳細はアドバンス編・質疑応答等辺りで)、取り組むには一朝一夕には行かない、険しいものであるな〜という印象はやはり変わらずな感じでした。

勉強してすぐに身に付く類のものではないでしょうし、参考文献を少しずつ読み解いてエッセンスを吸収して行きたいものですね。やっぱりDDD本(和訳)は購入して手元に置いておくべきか？(読むにしても冒頭1章辺りかな？^^;)


その他関連サイト：