「エヴァンス本も読まずにドメイン駆動設計とは何事か?」 参加ノート

modeling-how-to-learn.connpass.com

ちょうどエヴァンス本を読んでる時にこちらのイベントを目にしたので申し込んでみました。 自分用ノートです。

イントロダクション

  • 現場から学ぶモデル駆動設計 グループ
    • https://modeling-how-to-learn.connpass.com/
    • 実際に現場でやってどうだったかの肌感を共有する趣旨
    • コメント欄 >「ドメインエキスパート」って「現場のエキスパート」だなとつい最近気づいた。「現場で役立つシステム設計」って「ドメイン駆動設計」ですねww

エヴァンス本から今学べること

www.slideshare.net

  • エヴァンス本をどういう本として読むか?

    • 要求は定義されている前提で、ソフトウェアでどう設計していくかという本

      • ビジネスやサービスの本ではない
    • システム設計ではなく、アプリケーション設計の本である

      • どういう構成でシステムを組むか?ではなく、アプリケーションをどう設計するか、という内容
    • DB設計や画面設計については書かれてない

      • SoRとSoE
        • 既存の業務システムはSoR(System of Record)と言われ、正確に記録することを重視して設計されます。

        • 一方、SoE(System of Engagement)とは、ユーザーとのつながりを重視して設計されるシステムを指します。

        • https://www.cyzen.cloud/magazine/soe_sor
    • 設計の本で、要件定義・テスト・運用の話はしていない

      • エンジニアとビジネスの関わり方、インタラクティブなあり方について書かれている
      • 運用設計とはまた別
    • 設計の本だけど、設計工程の本ではない

      • コメント欄> Evans本として選択と集中があるってことですね。なんでも含めてしまうと焦点がぼやけてしまうんですよね。
    • エヴァンスのホームページでプロセスについてちょっと書かれている

  • 何が書かれているのか?

    • 考え方を示している
      • 具体的な手法を取り扱わず普遍的な考え方を示すことで、陳腐化しない
    • 考え方とは?
      • ソフトウェアに業務知識を反映させよう
        • そうすることで、柔軟に拡張したり変更したりできるようになる
        • 「反映させる」とは?
          • アプリケーションは分割と統合
            • どう部品化するか?→業務モデルに合わせて部品化していこう
        • 野球のミットがもし一枚板だったら硬いからボール取れない、軍手だと痛い
          • コメント欄> 第3部の導入文にでてくるはなしですね
          • コメント欄> リファクタリングしていくと、よく変わる部分と鉄板の部分が分かれてきて、使い込んだグローブみたいにソフトウェアがなってくよ、という感じの話ですよね。
    • どう受け止める?
      • 概念的に構造を揃えよう
        • MVCの場合、ユーザーのメンタルモデルをコンピュータモデルに持ち込む
        • どこまで業務モデルに合わせる?
          • サブシステム・パッケージ・クラス・メソッド・変数?

座談

  • ファウラーのエンタープライズアーキテクチャ

  • bouded contextをどう訳すかに悩んだ

    • コンテキスト境界?
    • 境界づけられたコンテキスト
  • 言葉とは差でしかない

  • 軽量DDDと言われがちですが、実装から入るのもありでは

    • Howだけでは実装できないので、実装中におのずとWhatと向き合うことになる
  • POEAA?

  • エクリチュール

  • エヴァンス本はソフトウェアエンジニアの人間賛歌

  • 主役はValue Object、大きな単位で見る時はパッケージ

    • 三部四部はパッケージの話
      • 責務のレイヤーとか
  • パッケージを可視化するツール

    • 意外とJIGで視覚的な図を出してみるとパッケージの依存関係が思ってたのと逆になってたりする
      • https://github.com/dddjava/jig
        • 特に値オブジェクトまで作るとなると、そういう全体像がないものが多すぎて脳がオーバーフローする
  • パッケージで区別して、パッケージで認識合わせするだけでも価値がある

  • サブシステム 〜 変数どこまできっちりDDDのニュアンスを適用するか?

    • サブシステム→変数のトップダウンでは、間違った状態で細部まで行ってしまうことがある
    • 小さいところから、全体をみながらビルドアップしていく方が結果的には安定しているのかも
      • コメント欄> 全体を正しく組むために下から組み上げる。わかる。
      • コメント欄> 両方向からって感じだけどな トップダウンで引けることって経験済みのことくらいしか無理だし
  • しなやかな設計の章を読もう

  • メイヤー本はおすすめ

  • コメント欄> 今までDDD本を新規メンバーに読んどいてとすると誰も完読した経験がないです。ここへの対策何かあったりしますでしょうか(苦笑

    • 1部と3部だけでいいんじゃないですか
    • 要約文を提出させるとかw
    • 太字のところ、導入部のみだけとか

自分のツイート