8

名前があり、オブジェクトのように聞こえますが、5 つの主要な DDD ビルディング ブロックの 1 つの責任と重複するものが存在するドメイン モデル内の概念に遭遇した場合、このオブジェクトに名前を付けたり、設計を処理したりするためのベスト プラクティスは何ですか?実際の実装にその名前またはフレーズが含まれている場合と含まれていない場合がありますか?

より具体的な例を挙げると、DDD の精神でタイム トラッキング アプリケーションを設計していて、ドメインの専門家が「タイム ログ」と呼ぶものに遭遇したとしましょう。全従業員のパンチアウトタイム。

この情報を基に、既存の時間エントリを照会し、新しいまたは修正された時間ログ エントリを永続化できる TimeLog という名前のクラスが作成された場合、そのようなクラスが実際に DDD リポジトリの役割を果たしていると最初に考えました。簡単にするために、さまざまな議論とリファクタリングの後、ログエントリは本質的にそれ自体の集約ルートであり、対応するリポジトリが必要であるという結論に達したと仮定します。

ここで、ユビキタス言語の DDD の概念により近いと思われるTimeLogという名前をリポジトリに付けるか、 TimeLogEntryRepositoryと呼ぶかのオプションが残されています。これは、クエリ/永続化する集約ルートの後にリポジトリを命名するためのより一般的な規則に適合しているようです。私は TimeLog を使用するという考えに傾倒しています。これは、ドメイン モデルで TimeLog が果たす実際の役割をより説明し、ドメインの専門家に設計を伝えるのに役立つはずだからです。一方、TimeLogEntryRepository を使用するという選択は、既存の DDD 規則に従うため、開発者が設計を理解しやすくなります。妥協案として、TimeLog の命名を使用することもできますが、すべてのリポジトリに IRepository インターフェイスを実装するか、共通のリポジトリ基本クラスから継承させて、開発者がドメイン モデルを構成する他のリポジトリ クラスを見つけて区別できるようにします。

このような場合のベストプラクティスは何ですか? サービスは、開発者が SomeComplexActivityService のように「サービス」サフィックスを使用して通常名前を付ける典型的な DDD ビルディング ブロックの別の部分であるため、おそらく同じタイプの問題がサービスで発生していることがわかりますが、エンティティと値オブジェクトの場合、これは実際には問題ではありません. 私は特に、DDD の経験が豊富な他の人が何を言わなければならないかを知りたいと思っています。

4

2 に答える 2

6

私は個人的に好きTimeLogです。

テクノロジーではなくビジネスに焦点を移すと、それがどれほど簡単になるかは実際には驚くべきことです。適切な命名は、その焦点を鋭く保つための主要な武器です。

同じことがサービスにも当てはまります-の代わりにApplicationRegistrationService、私はを使用しますApplicationRegistrator。

これは、リポジトリに関する非常に優れた記事です。

于 2011-05-03T10:53:44.970 に答える
2

私は2番目の@Arnis L.の提案です。また、DDDに関して、ドメインは実際のUL（ユビキタス言語）を反映する必要があることも付け加えておきます。これは、ビジネス分析や、多くの場合非技術者である他の人々と共有します。だから私はあなたが彼らと話すことになると思いTimeLogますTimeLogEntryRepository. リポジトリは単なるパターンであり、その名前は命名規則にあってはなりません。

于 2012-04-16T14:12:50.453 に答える