1

私は最初に、現在の設計でドメインモデルを実現しようとしているのではないことを言いたいと思います。

そうは言っても、私は現在、次のようなアーキテクチャを構築しています。

UI DTO <=> Service DTO <=> Business/Database DTO (using AutoMapper)

私はEricEvanのDDDの本を読んでいて、 Greg YoungのDDDプロジェクトが失敗する7つの理由を見てきました。そして、貧血モデルを恐れています。私はDDDを処方していませんが、非常に類似したものを前後にマッピングし続けるのが面倒になるほど多くのレイヤーを作成したくありません。

しかし、私が行うセットアップを持っている理由は2つあります。変更のしやすさとあいまいさ

  • 変更のしやすさ：パブリックオブジェクトがサービスを介して公開されており、UIとビジネスオブジェクトを内部で使用している場合、既存のAPIを壊すことなく自由に変更を加えることができます。しかし、おそらく1つのDTOを使用して、DTOが逸脱し始めた場合にリファクタリングすることができますか？
  • あいまいさ：パブリックオブジェクトを公開することはできますが、完全なオブジェクトとその実装が内部にある場合は公開できません。これは安全な製品である必要があるので、私はその準備をしています。しかし、多分また、後でそれをリファクタリングすることができますか？

だから、私の質問はこれです：私の現在のモデルは意味がありますか、それとも後で問題を求めていますか？これらのオブジェクトは主にDTOであるため、問題ありませんか？Evanの本でさえ、彼は、このモデルが異なるサーバーに分散されるように計画されている場合は問題ないことを示唆していますか？それで、UI、サービス、およびDBレイヤーを異なるサーバー上に配置できるようにすることを計画しているので、この理由だけでレイヤー化は問題ありません（現在は必要ないため、現在は使用されていません）。

オーバーアーキテクチャを認識しようとしているだけですが、同時にアンダーアーキテクチャを回避しようとしています.....それで、このモデル構造は私の現在の実装にとって良いのか悪いのか？

4

2 に答える 2

2

これは、私のチームが ASP.NET MVC と WCF を使用した開発に使用するパターンです。ビジネス/データベースの dto はエンティティ フレームワーク クラスにマップされ、サービスの dto は WCF サービスに出入りする POCO クラス/DataContract にマップされ、 UI dto は MVC モデルにマップされます。

これは冗長に思えるかもしれませんが、スタック内の 3 つの dto がすべて同じプロパティを持つ設計に、各レイヤーのニーズが当てはまることはめったにありません。それらが異なる傾向にある 1 つの例は、ルックアップ テーブルへの外部キーです。データベース層では、これは int で表されますが、サービス層では、型の安全性を課すために列挙型としてより適切にモデル化されます。最後に、UI では、このフィールドはローカライズされたに変換されます。ユーザーに表示する文字列。

オーバー アーキテクトに対するあなたの恐れに関して言えば、物事をシンプルに保つことについて何か言いたいことがあります。このパターンを使用するように駆り立てる要因は、UI とは別にアプリケーション層をデプロイする必要があるか、または単純に 2 人以上の開発者がいるチームで作業しているということです。チームが成長するにつれて、チーム メンバーがビジネス層を迂回してデータベースに直接アクセスする可能性が大幅に高まります。そうすることで、それらは常に、あなたが持っているアスペクト指向プログラミングの目的を無効にします-つまり、ものはログに記録されず、トランザクションにラップされません。余分なレイヤーを追加して別のサーバーに移動すると、問題が明確に分離され、さらに重要なことに、それが強制されます。1 人か 2 人のチームであれば、これを回避するのに十分な規律を持っているかもしれませんが、成長するにつれて、

それが役立つことを願っています!

于 2012-11-07T05:40:48.310 に答える
0

私は最初に、ドメインモデルを実現しようとしているのではないと言いたいです

..。

貧血モデルを恐れています

これらの2つは私には少し矛盾しているようです。

私はDDDを処方していませんが、非常に類似したものを前後にマッピングし続けるのが面倒になるほど多くのレイヤーを作成したくありません。

DDDで提案されている貧血またはリッチドメインモデルの概念は、レイヤーの数、これらのレイヤーで使用されるデータ構造、およびこれらのデータ構造がどのように変換され、あるレイヤーから別のレイヤーに渡されるかについては何も想定していません。

リッチドメインモデルは、ビジネスレイヤーにデータに加えて動作をカプセル化するドメインオブジェクトが含まれていることを意味するだけです。豊富な内部ドメインモデルを完全に持つことができ、ファサードとして機能する公共サービスのみをその動作に公開し、必要に応じてその下に10億のレイヤーを配置し、それぞれが独自の種類のDTOを操作します。

だから、私の質問はこれです：私の現在のモデルは意味がありますか、それとも後で問題を求めていますか？[...]私は、過剰なアーキテクチャに気づこうとしているだけですが、同時に、不十分なアーキテクチャを避けようとしています。

あなたのモデルは、過剰に設計されているようには見えません。階層化されたアプリケーションの自然な層のみを反映します。Dougが言ったように、DTOは同じ目的を果たさないため、各レイヤーで少し異なるのはごく普通のことです。

于 2012-11-07T12:40:19.410 に答える