読者です 読者をやめる 読者になる 読者になる

関西DDD.java 【京都再演】ドメイン駆動設計のためのオブジェクト指向入門 #kandddj

DDD 開発

kansaiddd.connpass.com

実践ドメイン駆動設計エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)なんか読んでいるけど、実際にはどうやりゃいいのかなというところがちょっとでも情報つかめるならと、行ってきました。

実践ドメイン駆動設計

実践ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

質疑応答でドキュメントはどうすればいいのか、みたいなところが質問に出ていたけど結局のところ業務知識が豊富な技術者を作り上げるorドキュメントを書いて業務知識を残すという作業のコストでどっちがコスト低いかというところなんだろうか。でも、新規ならまだしもこれまでに積み重なってきたルール類を持つ業務だったりしたら、先にドキュメントとして残すなり作るなりのコストを払ったほうがのちのち良いような気がします。メンテは必要だけど、それこそその人の持ってる知識がバージョンアップされるかどうかもある意味メンテなので、書くほうがいいんじゃないかなぁ。

ただ実装そのまま書いたようなものとかは無駄だと思うので、そういうのはいらない。そのへんはまず「コードを書こう」でいいかと。

あとフロントエンドとDDDの話で個人的に思ってるのは、もうでかい規模だと丸まる一つ別のドメインとして考えるほうがいいのかなーという気がしないでもない。と思ったら同じ日に別の場所でやってたイベントで大型フロントエンド開発におけるTypeScriptとDDD // Speaker Deckという発表があったらしい。この二槽式というアプローチはわりと納得感があるので、今後考えてみたい。

以下、メモ。

ドメイン駆動設計のためのオブジェクト指向入門(増田さん)

  • 実装に振り切った内容、具体例、増田さんのベスト
  • 転職支援サビースでの事例で説明
  • 基礎知識
    • ドメイン駆動設計
      • ドメイン層のソフトウェア設計
      • インクリメンタルな設計(XP)
      • ドメインの知識を噛み砕く、言葉を使った意図の伝達、モデルと実装を結びつける
      • 技術者は言葉より技術のほうに行きがち => 技術者はドメインエキスパートといっしょに分析するべき(認識違いなどを修正していく)
      • 毎日分析毎日コード書く(フェーズに分けたりしない)
        • 保守の現場ではあたりまえ
      • 会話をしながら意図を確認、コードと動くソフトウェアで意図を確認
    • オブジェクト指向設計(具体的なXPの話)
      • やって楽になった
      • データクラスと昨日クラスを分けると、機能クラスにコードの重複が増え変更が飛び火する
      • 変更した箇所のテストOKならほかもOKという確信(実際OKかどうかはまた別)
    • ドメインを学び学んだことをコードで表現
    • 表層の設計はそうなっているけど、実際のところ変更すると苦しいなどという話がある
      • じゃあどうするのか?どうしたら楽になるのかというところを示す
    • 業務ロジックが散らばってる => つらい、いかにドメイン層に押し込めるか
  • ドメイン層のオブジェクト
    • POJO
      • Not Plain Old Java Beans
    • 業務の関心ごとを表現したオブジェクト
      • 業務で知りたいこと
      • 業務のルール
      • ルールが破られた時の業務ルール
        • if文一発でいけるものも業務ルールであれば一手間二手間かける必要がある
      • 業務サービスの実行役
        • 判断の結果
        • 計算の結果
        • 加工の結果
        • 基本データ型を返さない
    • 変更コストが下がる設計
      • ロジックが一箇所に集まってる
        • 使う側が一つメソッド呼び出せば、加工されたオブジェクトがかえってくる
    • 画面一覧や機能一覧などとドメインの設計は異なる
    • ネットワーク構造
      • メタファ
        • LAN(オブジェクトの集約)
        • INTERNET(システム全体)
    • 工法
      • インクリメンタルに開発
      • フェーズ分けるとコストが悪い
      • 分析設計実装を人でわけない
      • 独自の型を設計する
      • オブジェクトのコラボレーションを設計する
      • howを隠蔽する
        • Javaの言語仕様なんかがドメイン層で表立って出てきてはいけない
      • ドメイン層は独自の型だらけにする
        • 利用者の関心ごと=型
        • 基本データ型=コンピュータの関心ごと
      • バートランドメイヤーの本
        • 契約による設計
        • 顧客クラス側で判断加工計算してしまうのはダメ
  • 事例
    • 転職支援サービス
    • ドメイン層の隔離 中級でだいぶ楽になる
      • 中級をがんばってやるのが価値になる
    • オブジェクトとSQLマッピングで行ける
    • メトリクスとるとドメイン層のクラス数が多くなる
      • 集約1つに対して10のクラスがぶら下がる
      • クラスの行数は大体30〜60行、シンプル!
    • 仕事に対して、勤務条件、給与、休暇……などいろいろぶらさがるので、大体クラス数は膨れ上がる
      • 顧客の下にいろいろある、仕事の下にいろいろある
    • ドメインオブジェクト「善い部品」
      • 分解のしやすさ、組み立てやすさ、わかりやすさ、連続性、保護性
    • エヴァンス本10章に善い部品の基準
    • 参照オブジェクト(Entityパターン)
      • 関心ごとへの参照点
      • 顧客との会話の語彙の起点
    • 値オブジェクトにロジックをかき集められたらだいぶ変わる
    • 転職回数なんかを数値ではなく、値オブジェクトとしてもつ
    • 値オブジェクトでコードが安定する
    • 一覧オブジェクト
      • ListやSetをラップしたドメインオブジェクト
      • SQLの抽出条件を単純にして、微妙な抽出や加工は一覧オブジェクトにやらせる
    • 区分オブジェクト
      • 振る舞いを持ったEnum
      • if文/switch文を描かない工夫
      • 関心ごとの明示的なコード表現
    • HowよりWhat
      • 汎用 => 限定
  • 学び方のヒント(メイヤー本の受け売り)
    • 用語を学ぶ
    • 実際にコードを書く
    • 読みなおす
  • 質疑
    • 使う人とそれがしたいものはなにか(ユーザストーリーマッピングと同じ)
    • どういう業務なのか

フロントエンドはDDDの夢を見るか ゆきーんさん

  • 求職者向け転職支援サービス
  • knockout.jsつらそう
  • クライアントがデザイン => 特に考えることもなくはじめる => 突然フロントエンドも担当
  • 画面は使う方の関心が強いところ
  • ドメインモデルを蒸留できるところまでいけてなかったので、ヘルプとの連携もうまくいかず => 仕切り直し
  • ドメインモデルと画面
    • ドメインモデルの構造のまま画面に公開
    • ドメインモデルの強弱を画面に反映させたかった
  • ある日追加要件
    • プロフィールにTOEICなどを追加
    • プロフィールとスキルの関連 => これはキャリアの情報だ
    • 適切なスカウトを行うためのドメインモデルがなかった!
  • ドメインモデルと画面の関係
    • デザイナさんとコミュニケーションを取りやすかった
    • デザイナさんが確認しやすかった
    • URLが長くなる!(IEの制限が……)
  • CSS難しい
  • JavaScriptとDDD

ドメイン駆動設計を軽快に実践するための はるじっくさん

  • 重厚さ
    • モデル図しっかり書く
    • モデル図を常に更新 => こんなことするならコード書きたい
    • モデル図で会話してくれるドメインエキスパートっているの?
    • そもそもドメインエキスパートが忙しい、ドメインエキスパートいない
  • 軽快さ
    • コードファースト
    • モデル図はスナップショット
    • ドメインエキスパートを待たない
    • フィードバックは動くUIからで良しとする
  • モデルを洗練していくための素早いフィードバックループ
    • 使う人からのフィードバック プレゼンテーション層
    • テスト書きにくい、読めるテストが書けない アプリケーション層
    • データソース層はノイズになるフィードバックが多い
  • 集約ルートが開発の基本単位
  • プレゼンテーション層まで作ってしまう
    • すっかすかな状態でも動く状態まで持っていく
  • 動かない状態 => フィードバックが長い、動く状態 => 短い
  • テストを書く
    • 初回のフィードバックはない
    • 実装していくなかでいろいろ来る
  • プレゼンテーション層の実装
  • コードから得られないもの
    • 集約をまたぐ俯瞰視点からの違和感や不整合 => 深いモデルに到達するためには必要か
  • 最初は貧血症でもいい
    • 漏れでた業務知識を後からでもドメインモデルに戻せるようにする