「ドメイン駆動設計 モデリング/実装入門勉強会」オンライン参加レポ

概要

• connpassからの引用です
  • ハッシュタグ #ddd_guide
  • 松岡さん
  • Loglassさん
    • DDD紹介記事
  • 当日のスライド

DDDとは

• 抽象的に言うと、「ソフトウェア開発手法の一つ」である
• そもそも、ソフトウェアはなんのためにつくるのか
  • ソフトウェアを適用する対象の何らかの問題を解決するため
    • この「ソフトウェアで問題解決しようとする対象」を「ドメイン」と呼ぶ。
    • Domain-driven design
    • DDD Reference
    • 「ドメインモデリングによってソフトウェアの価値を高める」ことを目指す
    • DDDの目的は、コード品質の更に先にある

モデルとは

• 問題解決のために、物事の特定の側面を抽象化したもの
  • ドメインモデル：ドメインの問題を解決するためのモデル
  • データモデル：データベースに何かを永続化するためのモデル
  • ↑これらは別物であり、明確に区別する必要がある。
• 抽象化とは？
  • 現実世界の全ての要素をソフトウェアに落とし込むのは不可能
    • 必要なモデルは取り込みたい、不要なモデルは取り込みたくない
    • これの取捨選択が「抽象化」

良いモデル、悪いモデル

• 良いモデル：問題解決ができるモデル
• 良くないモデル：問題解決ができないモデル
  • 現実に即していない
  • やりたいことができない
• モデルがイケてないと、その後の実装がどんなに素晴らしくても良いソフトウェアにはならない
• 良いモデルを作るためには
  • ドメインに詳しい人から知識を得る
  • 運用した知見をモデルにフィードバックして改善する
  • モデルは最初から完成しない、改善していくもの
• コードとモデルが乖離すると
  • モデルの更新をコードに正しく反映できているかわからなくなる
    • 意図していない実装を生みやすくなる
  • モデルからコードを理解しにくくなる
    • ドメインに対する理解もできない
    • モデルは改善されない
    • ソフトウェアの価値を高めにくくなる
• モデルそのまま表現したコードとなるのが望ましい
  • オブジェクトでモデルを表現する
• モデルは継続的に改善したい
  • コードにも継続的に反映しないといけない
  • 頻繁な変更に耐えうるには、拡張性の高い設計が必要
  • そこで生まれたのが、EntityやRepositoryなどのデザインパターン
• 軽量DDD：DDDの実装パターンだけ取り入れること
  • 拡張性の高いベストプラクティスだけを取り入れる
    • それだけでも十分価値ある
  • コード品質を上げると、ようやくモデリングする余地が生まれると考えることもできる

モデリングから実装まで

• DDDのアプローチ
  • ①ドメインについての理解を深め、モデルを継続的に改善する
  • ②モデルを継続的にソフトウェアに反映する
• どうやってモデリングするのか
  • 決まった方法はない
  • 今回はユースケース図、ドメインモデル図によるモデリングを紹介
• ユースケース図
  • ユーザーとアプリケーションの相互作用を定義する
  • ドメイン図作成の範囲も決める
  • 意義
    • 具体化、言語化
    • ドメイン図作成の範囲を限定する
• ドメインモデル図
  • クラス図の簡易版
  • ふるまいは不要
  • 属性も代表的なものだけでOK
  • 業務の「ルール・制約」(＝ドメイン知識)を吹き出しで記述する
  • 集約の範囲を明記する
    • 集約：必ず守りたい強い整合性を持ったオブジェクトの集まり
• 実際のモデリング
  • 最初はホワイトボードに殴り書きでOK
  • レイヤーを定義し、「このレイヤーにはこういうクラスをつくる」というのを決める
  • 改善余地のあるコードから入り、リファクタリングしていく(p116〜135あたり)

プロジェクトへの導入方法のススメ

• DDD導入の進め方
  • お手本コードを作る
  • お手本に倣ってコードを書くようにチーム展開する
    • この段階では軽量DDDでも全然OK
  • あれ、ドメイン層には何書くべきだったっけとなったらドメインモデリングしてみる
  • ドメインモデル図を元にリファクタリングしていく
  • お手本コード展開から入る理由
    • 原理を理解して展開よりハードルが低いため
    • ドメイン層には何書くべきだったっけとなった方がモデリングの必要性を感じやすいため
    • どういうコードに落としこまれるのかがイメージできてからの方が、ドメインモデリングしやすいため
• 上達のイメージ
  • DDDのコーディング、モデリング共に一発では上手くできない
  • コーディングだけ、モデリングだけ上手くなるということもない
  • 両方相互に経験値をためながら上達していくしかない
  • 結局、このサイクルのどちらから入るか、という違いだけ
  • コーディングとモデリングを意識的に両方少しずつやってみるのが良い
• まとめ
  • DDDでは、「モデルを継続的に改善」「モデルの更新をソフトウェアに反映」のアプローチでソフトウェアの価値を高める
  • モデルの更新を反映しやすいように、モデルをそのまま表現する
  • その際にオブジェクト指向の手法を利用する
  • DDD戦術設計パターンは、保守性の高い設計のベストプラクティス
  • 設計パターンの適用とモデリングを両方使うと、ソフトウェアの価値を高められる
  • 実装と、モデリングを少しずつ着手してみよう

感想

• まずはモデリングから取り入れてみようと思ったが、モデリングだけではなくて、コーディングにも少しずつ取り組んでみようと思った。