イベントストームを使用する必要があるのはいつですか。
私は最近、ドメインモデルを構築するために、ドメインから理解を得るためのかなり合理的な方法として event storming のように思えます。私たちはドメイン内のイベントを理解しています。ドメインの専門家にとっては、日常生活で慣れているビジネスプロセスを伝えるために煮詰めてしまうため、これらのイベントを引き起こす可能性のあるコマンド、そして最終的には集合体を見つけ出します。
私が読んだすべてのことから、タマンのルールとビジネスロジックを理解することは非常に実行可能な方法のようです。
しかし、私がまだ理解していない点がたくさんあります。 1つ目は、プロジェクトの過程でイベントストーミングを使用する必要があるのはいつかということです。
私の疑問は、主にイベントストーミングと要件収集に関するもののようです。それは要件収集の直後に行われるべきですか、それとも要件収集の手法として見なされるべきですか？
要約すると、プロジェクトのどの段階でイベントストーミングの手法を使用する必要がありますか？
イベントストーミングは、ドメインまたはその一部の現在の状況の一般的な理解に到達するための手法です。イベントフローのステップは、作成する新しいソフトウェアに必ずしも対応しているわけではありません。既存のソフトウェアですでにサポートされているステップや、純粋に手動のステップを含めることもできます。
この種の理解は必要ですbefore要件の収集を開始することは理にかなっています（これは、同じ会議内で要件から始めることができないという意味ではありません）。次のような質問に答えるのに役立ちます
イベントフローのどのステップが、いくつかのソフトウェアまたは自動化によってサポートされるようになりますか？
どのステップが現在いくつかのソフトウェアでサポートされていますが、おそらくより効率的な方法で、異なる方法で処理されますか？
効率を上げるためにイベントフローをどこで変更できますか？
私たちは、この10年間、ワークフローのどこで変更を行うべきか、または行うことができるかを検討する必要がある場合はいつでも、このようなブレーンストーミングを頻繁に行ってきました。
ただし、これを「イベントストーム」と呼んだことはありません（実際に、この用語を以前に聞いたことがあるかどうかはわかりません）。通常、処理パイプラインまたはワークフローのデータフローに焦点を当てますが、ウィキペディアが「イベントストーミング」で説明しているものと本質的に同じです。このためにポストイットノートは必要ありません。消去可能なホワイトボードも機能します。
余談ですが、ドメインの専門家を雇ってもらいたい場合は、派手なブランド名や、DDDの本で読んだ過度の正式な規則を避けることをお勧めします。おそらくあなたと私よりも年上です。
これは、状況や達成したい結果によって異なります。典型的なBig Picture EventStormingは通常、プロジェクトのキックオフ時に発生し、多くの分野の専門家が共同学習とモデリングの取り組みに関与しています。
より小さく、より焦点を絞ったフォーマットでは、必要なドメインエキスパートは少なくなりますが、モデリングプロセスやソフトウェアメカニクスに深く関わっています。これらは通常、反復の開始時または重要な機能を探索するときに発生します。
要件が私に集まっているように見えます。ポストイットのメモで終わりました。私は 似たようなもの に、マーケティング名を付けることを気にせずに主張しました。
プロジェクトの進行中にイベントストームを使用する必要があるのはいつですか？
基になるビジネスが変化したとき。
ドメインイベントは、ドメインエキスパートが気にするものです。彼らの思いが変わったら、あなたは彼らに対処する必要があります。
もちろん、プロジェクトを最初に開始するときにもこれを行う必要があります。次に、これらのイベントのほとんどを学びます。