#devsumiC 積ん読状態のドメイン駆動設計をちゃんと読むきっかけづくりに「ドメイン駆動設計再入門」に参加してきました

#devsumiC 「IT アーキテクトの役割と責任」は大変エモしろかった - #garagekidztweetzに引き続いて、devsumi2015 に参加してきたレポート第二弾。

正直、今回は自分的にはこのセッションに出ることが一番の目的だったと言っても過言ではなかったセッション、「ドメイン駆動設計再入門」

実は恥ずかしながら、わたしの場合、エリック・エヴァンスのドメイン駆動設計が積ん読状態になっていたもので、ちゃんと読むきっかけづくりに良さそうだというので参加させてもらいました。

さすが翻訳者本人によるセッションだったので、エリック・エヴァンスのドメイン駆動設計を読む垣根が大分下がりました。まずは第一部だけでも読みきろうと思います。

というわけで、以降はわたしがとってきたメモの共有です。

20-C-3 ドメイン駆動設計再入門

なんで再なのか？
- 原著が書かれて 10 年
  - 訳されて 4 年
  - あらためて DDD ってやろうとするとどうなるの？を話す
code を書く人にも書かない人にも響く内容のはず
@digitalsoul0124
- d.hatena.ne.jp/digitalsoul
- ときどき翻訳
  - ドメイン駆動設計
DDD nutshell
- 基礎
  - 非常に厚い本 (500p 超) ではあるが、読む人の文化圏がある
  - モデルとは？
    - モデルとは知識の表象である
      - MVC - 1979
      - Trygve M.H. Reenskaug
    - メンタルモデルを写しとるもの
    - 人は自分の抱える業務にこういうものだというイメージをもっているもの
  - MVC から DCI へ
    過去のブログに書いてある
    - モデル・ビュー・コントローラ - Trygve Reenskaug - Digital Romanticism
    - DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
  - 本に書かれていること
    - 4 部構成
    - 第一部ドメインモデルを機能させる
      - 90p でここだけなら読めると思うよ
      - モデルと設計の核心の相互作用
        
        モデルと設計実装を結びつける -> モデル駆動設計
      - コミュニケーションの基盤
        
        モデルの言葉を会話でも使う -> ユビキタス言語
        
        ひとつの事象を表現する言葉を統一する (顧客、お客様、ユーザとかわけない)
      - 蒸留された知識
        
        ドメインエキスパートの知識の表現
      - モデルはソフトウェアの中核となる
      - モデルはビジネスパーソンと開発者をつなぐ
    - 第二部モデル駆動設計の構成要素
      - 結構これが鬼門
      - モデルの実装のために
        
        モデルのためのレイヤをつくる
        
        UI および永続化層との分離
        
        レイヤ化アーキテクチャ
        
        ドメインレイア内でのモデルをつくる
      - こんな感じでアプリケーションをつくりなさいということが書いてある
        
        クライアントレイアー
        
        リポジトリレイアー
    - 第三部より深い洞察へむかうリファクタリング
      - 個人的に面白いという。二部がつらかったら第三部へどうぞ
      - モデルの深化
        
        時間をかけてモデルは深まっていく
        
        モデリングは発見のプロセス
        
        ブレイクスルー
        
        深いモデルをつくるためのテクニック
        
        暗黙的な概念の明示化
        
        しなやかな設計
        
        先達からの学習
        
        デザインパターン
      - ドメインエキスパートのやっていることを言語化する
      - 読み物として読むのも面白い章
    - 第四部戦略的設計
      - モデリングのスケールアップ
        
        モデルの整合性
        
        モデルの協会設計
        
        蒸留 (フラットなモデルの中で大事なところとそうじゃないところがあるよね、という話)
        
        本質の抽出
        
        大規模な構造
        
        巨大なシステムの俯瞰
- あとにつづく本
  モデルを核としたシステム観
  - GOOS (2009)
    - Steve Freeman, Nat Pryce
    - 実践駆動開発
    - テストをガイドとして、オブジェクト指向のシステムを育てる
  - DSL (2010)
    - Martin Fowler
    - DSL はモデルの表層を取り巻くベニヤのようなものである
DDD の魅力
- 全員にとって魅力のあるもの (developer, PM, etc)
- テクニカルにどうするというよりも業務の分析をしっかりしようという話だから。
- ある抽象度でのモデリングは絶対に必要
  - システムを俯瞰してかんがえるとき第四部の考え方が参考になる
- ソフトウェアとしての本質感がある
  - モデルをソフトウェアの中に組み込んでいく
- SI の現場への福音
  - ある種、 IT の現場の閉塞感
    - サイロ (縦割り、横割り)
    - 滝
      - ウォーターフォール型のこと
    - 規律
      - あまり自分の頭をつかってつくるようになっていない
      - トランザクションスクリプトを書くような感じ
        
        ある種のつまらなさを感じてしまう
  - 顧客と会話しながら、
  - イテレーティブにインクリメンタルに
  - 変化に柔軟に対応しながら
  - 技術的に難易度が高いものをつくる
- しかしバランスが大事
システムの中の DDD
- モデルをどこまで保つべきか？
  - ビジネスよりの人、システムよりの人
  - より抽象度がたかいことをするのか？抽象度の低いことをするのか？
  - お互いに共感できる分には問題がないが
    - 何も考えないで下まで落とすと問題が起こる
- モデルを作るだけでいいのか？
  - ドメインレイヤの外側についても、もちろん設計、考慮しないといけない
    - UI
    - 永続化層
    - 他システムとの統合層
  - すべてを統合する
    - その方法論までは本は語ってくれないので自分で考えないといけない
- すべての機能は複雑なのか？
  - トランザクションスクリプト
    - ユーザの要求を満たす手続き
    - 損益分岐点を見極める -> 慣れた人に任せたらいいよね、と Fowler も言ってるｗ
      - トランザクションスクリプトでいいところはトランザクションスクリプトで書く
        
        そのほうがコストが低い段階もある
        
        複雑さは囲い込む
  - P of EAA
- 何を対象とするのか？
  - モデリングの対象は何にするのか？
    - システムの外側で起きることの配慮が DDD を始めると希薄になる
      - ユーザへの配慮 - ユーザがどういう風に使うのかということへの配慮
    - 顧客とおなじものをみる
- 成長するのはモデルだけなのか？
  - システムをとりまく流れは多様
    - 企業のビジネス
    - システムを使う人
  - システム全体の FB loop も合わせて設計していかないとダメ
  - 開発チームも成長する
    - スキルトランスファー
    - 異動
まとめ
- DDD は素晴らしい構想
- ただ DDD の内側だけで考えるのではなく、システム全体のことを考えるべき
最後に - 本のメッセージ
- 世界に対するエンジニアの貢献はコードの優劣/難易度では決まらない
- 業務エンジニアへの応援歌である
- システムを通じて世界に貢献する