2

http://i.stack.imgur.com/YZXZN.png（現在、画像を埋め込むことは許可されていません）

上記のクラスモデルで本当に助けを借りることができました。私は、大学でオブジェクト指向を学び、試験を書き、それに合格したが、実際のコードに原則を実装することに着手したことのない「それらの」開発者の1人であると言うのは恥ずかしいことです。成文化を始める前に、私は本当に座ってアプリケーションの設計を検討したことはありませんでした。したがって、私の設計とコーディングのスキルは、モノリシックなレガシーバンキングアプリケーションの開発と保守の重みの下でゆっくりと衰退し、停滞しています。これから何年も経った後、私は間違いなく変化の時だと判断しました！私はデザインパターン、DDD、NoSQL、DIなどの世界を深く掘り下げてきました。この2週間は、私にとって非常に激しい経験でした。また、大企業や銀行で働いていたときに見逃していた膨大な量のベストプラクティスや技術に涙を流しそうになったと思うこともあります。最先端のテクノロジーと優れたデザインアプローチからどれだけ離れていたのか、信じられませんでした。突然のすべてのスワスが、コーディング麻痺の状態に陥る恐れがありました。デザインをさらに微調整する必要がある、または特定のトピックについてさらに研究する必要があると感じたため、コーディングを開始できませんでした。ただし、十分です。プロジェクトをクラックして、少なくとも最初のイテレーションを行う必要があります。そして、すべての突然のスワスは、私をコーディング麻痺の状態に陥らせる恐れがありました！デザインをさらに微調整する必要がある、または特定のトピックについてさらに研究する必要があると感じたため、コーディングを開始できませんでした。ただし、十分です。プロジェクトをクラックして、少なくとも最初のイテレーションを行う必要があります。そして、すべての突然のスワスは、私をコーディング麻痺の状態に陥らせる恐れがありました！デザインをさらに微調整する必要がある、または特定のトピックについてさらに研究する必要があると感じたため、コーディングを開始できませんでした。ただし、十分です。プロジェクトをクラックして、少なくとも最初のイテレーションを行う必要があります。

とにかく、私の問題については、十分なドラマです：

ゴルフアプリのモデル作成に取り掛かりました。DDDにある程度準拠し、NoSQL（RavenDB）を利用したいので、次の要件に着手しました。

  • 私のプラットフォームスタックはWindows/IIS / MVC 3.0/RavenDBです
  • 骨材のルーツを見つける必要があります！私はそれらを、それ自体で存続することができる私のシステム内の唯一の要素として定義することに着手しました。他のすべては、単に集合体の「サブコンポーネント」と見なしました。実際の動作はまだ定義されていないことに注意してください。
  • 私の集約ルートは、RavenDBドキュメントストアに実際に保持される唯一のクラスであり、「現状のまま」保持されます。大きなツリーのようなクラス構造を持つことは、実現されるパフォーマンス上の利点の観点から、RavenDBの最良のシナリオであるように思われます。
  • RavenDB APIは流暢で非常に軽量であると感じているため、リポジトリレイヤーの必要性は感じていません（Ayendeの投稿の一部をフォローしています）。必要に応じて、コントローラーのカスタムアクション属性を使用してセッションを開いたり閉じたりするだけです。リポジトリレイヤーなしでテストするのは難しいかもしれませんが、確かにいくつかの「メモリ内」ドメインオブジェクトをモックすることができるはずです。
  • DBへの書き込みは、別のサービスレイヤーで行われます。
  • ある時点で私は立ち止まり、「いったいどこに自分のドメインの振る舞いを置くつもりなのか！？」と自問しました。Webの検索から得られた一般的なコンセンサスは、ドメイン（エンティティ）に動作（ビジネスロジック）を持たせず、すべてをサービスレイヤーで処理する必要があることを示しているようです。しかし、Eric Evansをいくつか読んだ後、私のドメインの動作の多くがそこに存在するはずだと確信しています...ドメイン内に！

質問 -DDDと建築設計の分野における善意の初心者として、私は少なくとも正しい方向に進んでいますか、それとも破壊される運命にありますか？-上記に対する考え、警告、建設的な批判、洞察をいただければ幸いです。

4

3 に答える 3

3

すべてについて過度に学術的であり、分析に長くとどまることに対抗するには、まずそれを機能させます。次に、それをきれいにします。

動作を可能な限りデータの近くに置きます。クラスに責任を明確に割り当てることができないサービスを使用します（たとえば、「送金」メソッドをSavingsAccountクラスに含める必要がありますか？）。サービスは集合体の一部にすることができます。

リポジトリを使用してください（私はAyendeに同意しません）。DB書き込みに別のサービスレイヤーを使用するとおっしゃっています。リポジトリは、そのレイヤーを後回しにするのに最適なインターフェースです。また、完璧なテストシームでもあります。

クラス図を完全に調べていませんでしたが、あちこちで継承を使いすぎている可能性があります。継承よりも構成を優先します。継承は醜い頭をすぐに育てることができます。

集約ルートを選択する場合、重要な基準はライフサイクルです。アグリゲートルートが停止すると、アグリゲート内の他のすべても停止します。アグリゲートルートも制御され、アグリゲート外のすべてがそれを通過します。疑わしい場合は、それらをたくさん作成してください（単一エンティティの集合体）。ドキュメントデータベースでは、通常、集計ごとにドキュメントを保存するため、選択方法とある程度一致します。さまざまな集計への参照のIDを格納します。

于 2012-05-12T03:15:28.860 に答える
0

そうですね、うさぎの穴を掘り下げることは短期的には生産性を向上させませんが、長期的には開発者として成熟するのに役立つかもしれません。DDDやNoSQLなどには、学習するだけで何年も費やすことができるほどたくさんあります。

次のプロジェクトを成功させたい場合は、自分が知っていることに固執し、新しい手法を徐々に導入して、誰かが我慢しなければならない「ベストプラクティス」に依存せずに、常に完全に制御できるようにすることをお勧めします。君。

于 2012-05-12T02:24:22.893 に答える
0

まず、より専門的になるための措置を講じることを決定したことを祝福します。私はこの業界での職業の欠如に絶望し、80％のカウボーイ/ハッカー20％の専門家の間を歩いているように感じることがあります。

あなたの質問に：

  • Vaughn Veronによるこの記事を読んだことがありますか？そうでない場合は、する必要があります。骨材を設計するための優れたガイドを提供しますが、その複雑さは過小評価されていると思います。
  • モデルを見て、実際に集計を定義したかどうかわかりませんか？アグリゲートルートを特定したことはわかりますが、アグリゲートには明確な境界があり、他のアグリゲートから分離されている必要があります（つまり、他のアグリゲートルートを参照するエンティティがないため、IDを参照するようにします）。プロパティ名RefereeUserIDList は、実際にこれを行っていることを示唆していますが、図は、実際の「ユーザー」集約ルートへの参照を保持していることを示しています。
  • アグリゲートとルート、およびモデルデザインを特定するという点では、これは動作要件に完全に対応しているため、ここで役立つとは思いません。ただし、データ構造ではなく、動作に基づいて設計を行うようにしてください。移行するのは難しい考え方ですが、データベース構造を描写しないようにしてください。
  • Ayendeがリポジトリについて言ったことを読んでいませんが、Raven APIをモックできる限り（彼がRhinoモックを作成したことを前提としています）、問題はないはずです。
  • おそらく最も重要なのは、すべてのドメインロジックをサービスレイヤーに入れないことです。最終的には、反キリストに相当するDDDである貧血ドメインモデルになります。
  • 個人的にDDDを学ぶとき、私はすべての原則を理解しましたが、理論を実践に移そうとするときに苦労しました。正直なところ、DDDを補完するプリンシパルCQRSを理解して以来、私はそれで本当に成功しただけだと思います。グレッグ・ヤングの主題に関するいくつかのビデオを見ることを本当にお勧めします。
于 2012-05-18T12:52:43.530 に答える