ライブモデリングとコーディングで理解するDDD (DDD勉強会2021#1)のでたときのメモ・雑感

ライブモデリングとコーディングで理解するDDD (DDD勉強会2021#1)

概要説明

• DDDしたよってなるとモデリングの話になることが多いとのこと
• DDDでモデリングしようとしたときに手法として、RADRがあがる
• この勉強会であがっているモデリング方法は独自でsudoという
  • システム関連図（s）
  • ユースケース図（u）
  • ドメインモデル図（d）：簡易化したクラス図のようなもの
  • オブジェクト図（o）：ドメインモデルの具体例を記した図
  • s->u->d->oの順番でやるとあったが、oやってからdでもよい（というかライブモデリングではdやってからo書いていた）
    • s->u->doって感じかな
• システム関連図はRADRのシステムコンテキスト図と似たもので、全くRADRと別ってわけではなさそう
• ドキュメントはdiagrams.netで書いていた
• 前提として２，３ヶ月でつくってまず動くものを作るような開発でライブモデリング
• このライブモデリングでは、一つのドキュメントにシステム関連図とユースケース図、ドメインモデル図/オブジェクト図を書いている

システム関連図をかく

• システム関連図
  • 現場に詳しい人とユーザーができることを明らかにしていく
  • 非エンジニアでもわかるような図
    • ドメインエキスパートといっしょに書いていく想定のよう
  • 要件や仕様を仮でもいいので決めてすすめて、おかしいところがでてきたらまた修正していく
    • まずはスピード優先で全体像をざっくりと明らかに

ユースケース図をかく

• このライブモデリングでは、一つのドキュメントにシステム関連図とユースケース図、ドメインモデル図/オブジェクト図を書いている
  • 一方で書いて、修正したほうがよければ他の図も合わせて修正していく
  • 矛盾があれば直していく
• ユースケース図を書いたら、ドメインモデル図を書きはじめる前に書く範囲を決める
• 関係者と話すときの議事録で各図を書いてしまうのもあり
• ドメインモデル図/オブジェクト図を書くときはまずオブジェクト図を書いて具体例から書いていく
  • 今回だと、以下のようにいくつか書いていた
    • 面接で松岡さんという人が、１次面接を10/1に合格して、２次面接は11/1に予定
    • 不合格になった田中さんは・・・
    • 内定の山本さんは・・・
• ドメインモデル図/オブジェクト図を書いて洗い出されたドメイン名がユビキタス言語の原本としやすい
  • 単語帳作るよりは、この図をそのまま使ったほうが、メンテナンスもしやすい
• ドメインモデル図では多重度を書いていくの大事
  • 今回だと採用選考のない面接はありうるのか？→あるならば面談ってものが存在してくる
• 集約についてはエンジニアだけで話してもよい
  • 詳細な説明なかったが、ざっくりというと変更の単位かな？
  • 実装の話になるので
• ドメインの英訳は必ず書いておく
  • フロントとバックエンドで異なる英訳をするとややこしくなるため
  • これはあったな。実際めんどくさくなりかけた。バックエンド側の単語をフロント側にそろえてリファクタリングした。結果よかった。横断してメンテすることもでてきたから。

図の使い方について

• 既存のプロジェクトのときも、詳しい人から聞いて作ると、そのあと引き継ぎでつかえる
• 図で書いたことはあくまでも仮説。
  • プロトタイプつくったり周囲とこの図について話したりして検証していく

コーディング

• 言語はkotlin
• enumで日本語変数 ScreeningStatusクラスに、選考中、内定、内定承諾...
  • python2ではできないなぁ
• 集約単位でファイルやパッケージをわけていく
  • パッケージは必ずわけるとのこと
• バリューオブジェクトは必須ではない。目的を考えて。杓子定規に使うのは違う
  • 機械的にやりがちな人なので心に刺さる
• モデルとコードは一致するように
  • 乖離があるとメンテナンスしづらくなる
  • あとからなぜそのコードになったのかわかりづらくなる