ドメイン駆動設計でのリファクタリング[終了]

私はプロジェクトに取り組み始めたばかりであり、ドメイン駆動設計（Eric Evansが定義するDomain-Driven Design：Tackling Complexity in the Heart of Software）を使用しています。私たちのプロジェクトは確かにこの設計の候補だと思いますエヴァンスが彼の本でそれを説明するパターン。

私は絶えずリファクタリングするという考えに苦労しています。

私は、どのプロジェクトでもリファクタリングが必要であり、ソフトウェアの変更に伴って必然的に起こることを知っています。ただし、私の経験では、リファクタリングは、ドメイン変更の理解としてではなく、開発チームのニーズが変化したときに発生します（Evansが言うように、「より深い洞察へのリファクタリング」）。私は、ドメインモデルの理解におけるブレークスルーに最も関心があります。小さな変更を加えることは理解していますが、モデルに大きな変更が必要な場合はどうなりますか？

より明確なドメインモデルを取得した後、リファクタリングする必要がある自分（および他の人）を説得する効果的な方法は何ですか？結局のところ、コードの編成またはパフォーマンスを改善するためのリファクタリングは、ユビキタス言語コードの観点から表現力を高めることとはまったく別のものである可能性があります。時々、リファクタリングするのに十分な時間がないように思えます。

幸いにも、SCRUMはそれをリファクタリングに役立てます。SCRUMの反復的な性質により、小さなピースを作成し、それを変更することが容易になります。しかし、時間の経過とともにそのピースは大きくなり、そのピースが大きくなりすぎて変更が困難になるとしたらどうでしょうか。

ドメイン駆動設計を採用するプロジェクトに取り組んだ人はいますか？もしそうなら、これについていくつかの洞察を得ることは素晴らしいでしょう。DDDを正しく理解するのは非常に難しいため、私は特にいくつかの成功事例を聞きたいと思います。

ありがとう！

私はしばらくの間、DDDの大ファンでした（テストフレームワークのセーフティネットの有無にかかわらず）。

新しい設計方法論を使用しているため、リファクタリングの全体的な概念とライフサイクルは変わりません。かなりの時間がかかる場合は、その時間を管理から得るために、プロジェクトに比例した利益をもたらす必要があります。

それを行うことに関して、私はドメインモデルの理解における「突破」のために、3 か月の主要なリファクタリングに参加しました。現在の動作を検証するためのテスト、予想される動作を検証するためのテスト、および呼び出しコードの変更が必要でした。ただし、そのメリットは大きく、企業は以前は必要であったが、それができなかった多くのことができるようになりました。本質的に、リファクタリングは本質的に「機能」でした。

ドメイン駆動設計でのリファクタリングは、「良い」リファクタリングではなく、ニーズに基づいて行われると思います。正しくないドメインモデルを特定するとすぐに、コード/システムは実際の問題を表していません。

適切な例として、私たちは最近、妥当なドメイン複雑度のアプリケーションに取り組みました。これは請求/契約システムであり、新しいタイプのレートを導入していました。私たちはアジャイルなプロセス、正確には2週間のスクラムを使用していました。

最初に、モデルで2つのレートが完全に分離されていて、契約を介した場合を除いて関係がなかったことがわかった。しかし、より多くのストーリーを完成させたとき、特に新しいレートを古いものとしてラップし始めてそれを機能させるために始めたとき、それらが実際には同じであることに気付きました。これは最初の警告サインでした。

話を短くするために、誤ったモデルでストーリーの90％を達成することができましたが、コードのすべての部分で新しいレートを古いものとしてラップするか、および/またはif newRate else oldRate EVERY whereを作成します。私たちはことわざのレンガ壁に頭をぶつけていました。プロジェクトのこの部分の途中で、完了までの時間は指数関数的であるか、正しくないドメインモデルでは機能しないことがわかっていました。そこで、弾丸をかみ、ストーリーを8つのストーリーに分割し、ドメインモデルをリファクタリングします。

私たちがプロジェクトを完成させたとき、私たちはそれを後から見れば正しいことであり、それを正しく行うための唯一のことであることがわかりました。

時間がかかりましたか？はい。ただし、それを行わなかった場合は、さらに時間がかかります。DDDは正しく行われましたか？おもしろいことに、当時はDDDについて知りませんでしたが、Eric EvansによるDDDワークショップに参加して間もなく、私と同僚ができることはすべてうなずきました。DDDを知っていれば、リファクタリングをはるかに早く取得できたので、時間を節約できたと思います。

ドメインモデルで問題が発生した場合は、修正することが重要です。私の経験では、ドメインモデルのいくつかを実装したときに、ドメインモデルがさまざまなエンティティにどのように接続するかを少し見落としました。

その結果、人々は意図されていない方法でモデルを作成し、モデルの他の部分を壊して「機能させる」ことを試みました。

ドメインモデルに問題があることに気づいたら、できるだけ早く変更してください。リファクタリングするまでに時間がかかると、ユーザーに関して変更するのが難しくなり、メンタルモデルが適応されるようになります。

コードの一部では、継続的なリファクタリングはやりすぎです。コードの他の部分（DDDでは、いわゆるCore Domain）には必要です。コードが本来あるべき姿ではないことを理解すると、開発者に追加の認知的負荷がかかり（ドメインの理解と現在の実装の違い）、それにより、さらなる進化がより困難になり、コストが高くなります。

問題は、「これらの進化は必要か？」です。コアドメイン（ビジネスに変化をもたらしている領域）では、答えは「はい！」です。それはドメインのポーションであるため、ビジネスはより懸念し、利害関係者に変化をもたらすものです。これは、ドメインモデルの柔軟性により、コードを完全な形に保ち、最小限の労力で次の要件を実装する準備ができている場所です。

ただし、すべてのアプリケーションコードに適用すると、コストが高くなります。ビジネスにとってそれほど重要ではない領域（DDD専門用語のサポートサブドメインまたはジェネリックサブドメイン）では、コア用に予約されているアプローチよりも洗練されていないアプローチが必要になる場合があります。