DDDのプラクティスに基づいて、このロジックはどこに向かうべきか、不要な依存関係を回避するにはどうすればよいですか？

Question

私は自分のウェブアプリケーションにジオ座標を検索し、保存し、それらの座標を使ってタイムゾーンを検索して保存するロジックを追加しています。私が最初に行ったことは、GeoCodeUser（）メソッドを他のマップ関連のタスクを行うために定義したMappingServiceに追加することでした。 2つのデータのルックアップは2つの異なるRESTサービスに依存していたため、2つのルックアップタスクをAddressGeoCoderとTimeZoneCoderに分割し、それらを使用してデータとUserRepositoryを取得して格納しました。この方法の奇妙な部分は、このメソッドはリポジトリと2つの 'コーダ'にアクセスする必要がありますが、クラスの他のメソッドはアクセスしませんでした。だから、私がそのサービスを使って他のことをするたびに、私は依存関係がなくなります。 「ユーザー」モデルオブジェクト自体に（それは異なる動作を調整だから）

• が、これはサービスにするか可能：だからここに私は疑問に思って何ですか？

• もしそうなら、依存関係&関心領域（すなわちUserGeoCodingService）、または関心領域（MappingService）に余分な依存関係を持つサービスを定義する必要がありますか？

あなたの洞察力に感謝します。

ジェームズ

Answer 1

IMHO、DDDは、すべてのモデルについてです、とドメインの専門家は、物事が働くと言う方法を表現します。私はこのドメインについてはあまり知らないので、何が理にかなっているかを指摘することはできません。あなたは、基礎となる専門家または一貫したモデルが必要です。まだモデルがない場合は、今すぐコーディングをやめ、モデルをビルドしてください。

まず、より良い洞察力を持ち、それに応じてクラスを作成するためのユビキタスな言語が必要です。関心領域に基づく分離は、ドメイン専門家にとってのみ意味がありますか？

ドメインの専門家はどのようにプロセスを説明しますか？彼らはAddressGeoCoder、TimeZoneCoderのような用語を使用していますか？もしそうなら、それは良いデザインです。それ以外の場合は、彼らがどのように考えるかを知ることをお勧めします。

レポジトリと2つのコーダを使用するメソッドが1つしかないクラスについては、いくつか考えられるアイデアがあります（ドメインに対して意味のあるものを参照または作成してください）。

• 唯一の方法はパラメータ
• からその依存関係を受け取る（あなたが言ったように、サービスのように、）他のいくつかのクラスにこのメソッドを抽出
• は、再び、GeoCodeUserDataのような（一つだけで、この3つのエンティティをまとめます
• ）これはドメインのために理にかなっている場合は、
）あなたのコンストラクタは、ドメインの専門家は、それが行われるべきであると言うのと同じ方法をヌルを受け入れ（およびエラーに対処しましょう
• これらの依存関係を含む、余分な作業を避けるために、依存性注入フレームワークを使用します「あなたは、ドメインのより深い洞察を得れば、ドメインの専門家

DDDによって検証あなたは他に持っているどのようなアイデア

も、リファクタリングの強烈な作品ですので、あなたが勝ったので、それは、もののためのテストを持って良いことです必要な変更をすることを恐れないでください。