All Articles

DDD Radio #1

2019/09/22に開催されたDDD Radio 公開収録 #1メモ。 ファシリテーターの松岡さん、スピーカーのかとじゅんさんすえなみさんミノ駆動さんの4人がDDDをどうやって導入したか、失敗などの事例について話すという内容。

以下は印象に残った箇所の所感。

メモ(無編集)はHackmdにアップしてます。

ドメインモデル

ユビキタス言語は作れたが、実装上の表現がうまくいかなった(かとじゅんさん)

実装上の表現、つまりはドメインオブジェクト外にビジネスロジックが漏れ出してしまっていたり、ドメインオブジェクトの情報が過多もしくは過少だということ。 これについてはドメインオブジェクトが定義されていないプロジェクトも近しいと思っていて、プレゼンテーション側のコードに判断や計算ロジックが書かれていたり、複数のファイルで似たような処理が実装されているようなケースが多いのかなという印象。

こういった事態になる要因としては、

  • 実装するべき箇所がわからない
  • 現状で既にビジネスロジックが散在している
  • ドメインに対する知識が浅かった
  • etc…

があると思っている。

単一の概念を指す単語が複数あって話す人によって異なるという経験が自分にはあったので、ユビキタス言語を作ったことは素直にすごいなと聴いていて感じた。

モデルの共有をいかにするかが課題(すえなみさん)

解決策は語られていなかったけれど、気になったトピックだったので書いた。

実装で扱う概念を開発チーム内で定義してしまうと乖離しやすい印象があるが、ビジネスサイドの人といかにすり合わせると良いのかが自分もわからない。開発チーム内にドメインエキスパートと呼ばれる業務に詳しい人がいると良いのかもしれないが、必ずしも居るとは限らないので開発内で個人の解釈を出し合って認識にズレがないか確認する程度は最低限した方が良いのだろうなとは思った。

リファクタリング

ファットモデル(ミノ駆動さん)

ドメインモデルでも触れたが様々な概念が実装されてしまっているのが原因。 ファットモデルを解消するためにバリューオブジェクトにして抽出することで、仕様の理解が深まりコードの品質も高まるといういいことづくしだったとのこと。

会社ではcode climateを使って技術的負債を可視化しているとのことだったので、負債を返したいときの説得材料としてこういったサービスを導入するのはおおいにアリだなと思う。(サービスの導入ができる会社であれば返済についてもオープンだとは思うが)