赤シャツエンジニア

赤シャツエンジニア

エリック・エヴァンスのドメイン駆動設計 1章を読んで

ddd-community-jp.connpass.com

上記のイベント参加前に「エリック・エヴァンスのドメイン駆動設計 1章」を読んでの殴り書きです。

活動のサイクル

  1. 開発者が(現時点で描ける)ドメインモデルを作成する
  2. ドメインエキスパートを含めたプロジェクト関係者と話す。話す内容は以下の通り
    • 現在着目しているシナリオ(つまりユースケース?)にドメインモデルが適合しているか?
    • ドメインモデルあるいはシナリオで登場する言葉に違和感はないか?
    • 不要な概念はないか?
  3. 結果を整理し、最初に戻る

現在着目しているシナリオにドメインモデルが適応しているか

  • 筆者の環境ではドメインモデルが書いてある資料を見て、その製品の有識者が「このパターン忘れてない?」「こんなときはどうするの?」という発言がそれに当たると考える

ドメインモデルあるいはシナリオで登場する言葉に違和感はないか?

  • そっちでは「XX」って書いてあるけど、普段は「YY」って言っているやつねという発言がそれにあたると考える
  • 2章をチラ見したら熱く語られている。とにかくばらばらの言葉を使っているとコストがあまりにも高くつきすぎる

不要な概念はないか

  • ドメインモデルが書いている資料をみて、設計者・有識者が「そのクラスいる?」「なんかかぶってない?」という発言がそれに当たると考える
  • 筆者の例では、以下のようなことがあった

電源制御のコンテキストの中で停電が発生した際のシステムのふるまいをモデリングしていた。 具体的には、停電発生時に、UPSが落ちきる前にシステムを安定状態に持っていくというものをモデルに入れていた。 しかし、電源制御なので、電源周りを責務するはずで、

  • 内外部の状態、指示に応じて電源をONしたりOFFしたりする
  • 電源の現在の状態を通知にしたり、要求に対して応答したりする

以上のことを実施するとおかしいという指摘が入った。 結果としてシステムを安定状態に持っていくのはシステムがわのコンテキスト側でモデリングし、 電源制御はUPS時間待機し、システムの安定状態を受信するか、UPS時間が満了した場合に電源を落とすというモデルに変更した。これで、モデルはすっきりし、電源制御の役割も明確化した。完ぺきではないかもしれないが、エヴァンス本でのモデルの蒸留(不要な概念の排除)を体験した。

所感

  • エヴァンス本にでてくるドメイン・エキスパートがミーティングに積極的だなと思いました
    • エリック・エヴァンスのドメイン駆動設計 輪読会 1回「序文、目次、索引」でも話されていましたが、ドメインエキスパートが近くにいなかったり、捕まらなかったりしてこれが実現できない現場はあるだろうなと
    • ここでは省略されていますが、ドメイン・エキスパートを据えることが設計・開発プロジェクトにとってどれだけ重要であるがということが共有されていないと難しいと感じた
    • 逆に、エヴァンスの例やDDDが実践されている組織はその認識が持てるような工夫があるのかもしれない