松岡さんが実践している、オブジェクトの責務を見つける時の工夫があれば知りたいです。私がよく実践しているのは、ユースケースシナリオを現場の人と作成しながら、システムの振る舞いや情報を大雑把にピックアップし、概念的なクラス図とシーケンス図を作成...

[little-hands]

Question

松岡さんが実践している、オブジェクトの責務を見つける時の工夫があれば知りたいです。

私がよく実践しているのは、ユースケースシナリオを現場の人と作成しながら、
システムの振る舞いや情報を大雑把にピックアップし、概念的なクラス図とシーケンス図を作成します。
その後、クラス間の関連見ながら、
「このオブジェクトはこのオブジェクトへのメッセージが必要であるならば、このクラスにはこういった役割があるな」
といった感じでクラスを再構成しつつ、このクラスにはこういった責務が相応しいと決めつけます。
（責務の判定基準としては、ロールステレオタイプを基準にすることが多いです）

ただ、このやり方を実践していると、どうしてもUML等で図の作成が必要になり、ドキュメントの作成に時間が掛かりすぎてると感じています。。
また、モデルを実装に反映させるタイミングで気づく責務も生まれたりして、「作成した設計図を手直しして、実装に戻る」ということを繰り返すことになり、成果物が完成した頃には、漏れとかが原因で設計図と実装の整合性がズレていて、どっちの責務が正しいのか考え直したりしてしまいます。。

効率のよいの責務の見つけ方とかあれば、ぜひ教えて欲しいです。

Answer

抽象的なドキュメントで認識合わせする、コーディングしてからモデリングに戻ってアップデートする、という方法は私もかなり近いと思います。
詳細な方法はこちらで紹介しているのでよろしければご参照ください。
https://www.youtube.com/watch?v=A2EU0paEVJ0

DDDでは、「モデリングは最初から完成せず、実装や設計やユーザーのフィードバックなどさまざまなタイミングでアップデートする方が良い」というスタンスです。そのため、ご質問の通り途中で設計図を手直しして実装に戻るという進め方は、最初に詰めきれなかったものを放置せず、きちんと軌道修正しているようなので私は良いのではと思いました。
さらに一つ進めるのであれば、「DDDのモデルを正とする」ということで発見があればモデルをアップデートし、実装と同期することを重視します。実装が先に行ってしまうこともあるかと思いますが、基本的にはモデルと同期はとります。
ドメインモデルは、最新にしておくとその後の仕様理解や、どこを変更するかという議論をする土台として使えるものになります。そのため、基本的には最新化するのがおすすめです。
設計初期は知識や想定が足りないのは避けられないので、開発しながら必要に応じて軌道修正することは避けられないと思います。
ご質問の進め方は素晴らしいと思いますので、モデルで認識を合わせることの重要性を認識し、モデルから更新して実相と乖離しないようにする都より良いのではないでしょうか。