問題タブ [domain-model]

私はGrailsを初めて使用するので、簡単な質問があればいいのですが。

私はDomainModelを持っており、このモデルの中には関連するモデル（1対多）があります。サービスとサービスを「n」タスクとしましょう。私は（findAllBy（）を介して）たとえば3つのサービスを選択し、すべてのサービスには少なくとも1つまたは3つのタスクがあります。

今私の質問。「foundServicesをJSONとしてレンダリング」を返したくありません。理由：世界中の人々に私のモデル定義といくつかの「秘密の」プロパティを知らせたくありません。これらはすべてデータベースのreturn/selectによって自動的に入力されます。それは正しい考えですか、それとも「セキュリティが多すぎて深すぎる」​​という考えですか？

そこで、これらのオブジェクトと同様の方法で、必要な関連データを返す方法を見つけようとしました。

私は試した：

1）これは「オーバーヘッド」が多すぎますか？

2）「OKは関係ありません。（検索結果から）DomainModel全体を返します」と思いますか

3）独自の「配列リスト」をまとめると、ドメインモデルと同様に、すべてのプロパティと各サービスの「n」タスクリストに簡単にアクセスできるようになります。

どうもありがとうございます！

私は、「SQL アンチパターン: データベース プログラミングの落とし穴を回避する」という本を、特に魔法の豆のアンチ パターンについて読んでいます。これは、ドメイン モデルを使用してアクティブ レコードを分離する図を示しており、Rails ではなく PHP での例を示しています。これを、ドメイン モデルとビュー/コントローラー間の HAS-A 集約、およびドメイン モデルとアクティブ レコード間の HAS-A 構成と呼んでいます (IこれはUMLの話だと思います）。

Rails では、モデル メソッドを使用してシン コントローラーのファット モデルを作成するのが一般的なようです。これらのメソッドは、他の関連モデルを操作して、特定のコントローラーで 1 つのモデルのみを使用できるようにする場合があります。しかし、Rails で完全なデカップリングを含むプラクティスがあるのだろうか?

つまり、コントローラーとアクティブレコードオブジェクト (テーブルにマップされる) の間のレイヤーとして機能するドメインモデルとして使用されるテーブルレスモデルまたはその他のクラスを作成して、コントローラーがより適切に分離され、何も知る必要がないようにすることです。基礎となるデータベースとその構造について。また、適用されるアプリケーション要件を説明していない CRUD メソッドから離れることもできます。これは、この本の別の批判です。

貧血ドメイン モデルを回避するためにどの程度注意を払う必要があるかについて、アドバイスを求めています。私たちは DDD を始めたばかりで、単純な設計上の決定に関する分析麻痺に苦しんでいます。私たちがこだわっている最新のポイントは、特定のビジネス ロジックが属する場所です。たとえば、Orderオブジェクトなどのプロパティがあります。たとえば、誰かが注文を間違えたために次のStatusようなコマンドを実行する必要があるとします。これはそれほど単純ではありません。UndoLastStatusを変更するだけでStatus、他の情報をログに記録し、プロパティを変更する必要があります。現実の世界では、これは純粋な管理タスクです。したがって、私が考える方法には、考えられる2つのオプションがあります。

• オプション 1: メソッドを order に追加して、 のようOrder.UndoLastStatus()にします。これは理にかなっていますが、実際にはドメインを反映していません。またOrder、システムの主要なオブジェクトであり、注文に関連するすべてが注文クラスに配置されると、手に負えなくなる可能性があります。

• オプション 2:Shopオブジェクトを作成し、さまざまな役割を表すさまざまなサービスを使用します。だから私は、、、およびを持っているかもしれShop.AdminServiceませShop.DispatchServiceんShop.InventoryService。したがって、この場合、私はShop.AdminService.UndoLastStatus(Order).

2 番目のオプションは、ドメインをより反映したものであり、開発者は実際に存在する同様の役割についてビジネスの専門家と話すことができます。しかし、それはまた貧血モデルに向かっています. 一般的には、どちらがより良い方法でしょうか?

ビジネス メソッドを使用してドメイン モデルを構築しようとしており、EF 4.1 で永続化を行っています。ここまでは順調ですね。

問題は、すべてのプロパティがドメイン クラスで public として公開されていることです。とにかく、それは少なくとも私がチュートリアルから学んだことです。つまり、ビジネス メソッド以外の不注意なプログラマによってクラス プロパティが変更されないという確固たる証拠はありません。カプセル化違反。

ISomething を導入してみましたが、TableAttribute はインターフェイスではなくクラスにのみ適用されるため、EF に DBSet を実行するように指示できません。TableAttribute をクラスに任せても、何かに ISomething を実装させると、EF は ISomething を認識しないため、DBSet.Add() を実行できません。

私が考えることができる唯一の方法は、インターフェイスを使用して CRUD 用に EF 4.1 の上に完全な抽象化レイヤーを作成することです。内部で、Something と ISomething の間の型変換を行います。それは非常に複雑で、EF の設計にはぽっかり穴が開いているように思えました。または、何かを見逃したに違いありません。

これをどのように解決しますか？

どうもありがとう。

私が読んでいるユニバーサル データ モデルの著者の 1 人は、彼の経験では、すべてのエンタープライズ システムの 50% は、当事者や作業努力などに対処する必要があるという点で「ユニバーサル」であり、25% はそのビジネス業界内でユニバーサルであり、残りは特定のビジネスに固有のものである (つまり、コーラ対ペプシ)。

しかし、私はこれに基づいて構築されたコードを認識しておらず、90 年代半ばに Fowler が行ったので、データ モデリングの観点とは対照的に、ドメインの観点からパターンを実際に見ている人を思いつきません。

DDD 志向の人で、ユニバーサル データ モデルの有用性について意見に基づいた経験を持っている人はいますか?

文字通り、パーソンとオーガニゼーションに限定されたパーティのサブタイプがあり、他の全員が役割に属していますか? もしそうなら、それをどのように実装しますか？

気に入っている実装ガイドラインやオープンソース システムはありますか?

乾杯、
ベリル

家のステータスを更新するためのPOSTリクエストを作成したいとしましょう。理想的には、このデータはある種のサービスレイヤーにある必要があります。通常、これには次のものが含まれます。

1. ユーザーを検証します-それらはまだアクティブですか、それとも管理者によって追い出されていますか？
2. houseidを確認してください-houseid/レコードは有効ですか？
3. ユーザーは家の詳細を見ることができますか？
4. ステータスを「オープン」または「クローズ」に更新

現実の世界/複雑なドメイン-ほとんどのビューは非常に複雑です。おそらく、その地域の家の数、家に関するコメントの数、家の詳細など、家の未解決のタスクの数を破棄する必要があります。 ..。。

つまり、上記のコードはすべてサービスレイヤー内にある可能性がありますが、例外がスローされた場合、ユーザーは家のステータスを更新できません。ビューにデータを入力するには、最初に家の詳細を取得する必要があります。サービスレイヤー内にロードした他のすべてのものをコントローラー内にロードするか、このデータをロードするサービスレイヤーへの別のインコベーション...

同じコードを何度も書き直すことなく、検証とすべての種類を実行して、ドメインモデルが保護されていることを確認するにはどうすればよいですか...

このコードはactionメソッド内にあり、サービスレイヤー内に簡単に含めることができます...

//注：_repoは、linqからsqlへの単純な抽象化です...

要するに-要約の家の詳細を取得し、（複数の利用可能なタスクから）タスクの詳細を取得し、タスクのコメントも取得します。それは私見の単純な見方であり、それほど複雑なものではありません。

この時点で、ユーザーは次のことができます。コメントの追加、タスクの閉じる/開く-権限がある場合（簡単にするためにコードは省略）、タスクの期日を設定するか、タスクの期日をクリアすることもできます。

UpdateTaskStatus-ステータスを更新できない場合は、コメントと同様に上記のビューを返す必要があります。コメントできない場合は、詳細ビューを返す必要があります-コメントを閉じることができます。

私は上記のコードがひどく構造化されていることを知っていますが、それを修正する方法についてのアドバイスをいただければ幸いです。

1. アクション内にすべての読み取り専用コードを残します。各ビューが異なる可能性があるため、ここでサービスレイヤーが干渉することは望ましくありません。
2. 更新/編集を「保護」し、これをサービスレイヤーまたはコアプロジェクト（個別のc＃クラスライブラリ）またはドメインレイヤー内に保持したいのですが、そのコードハンドル検証をどのように記述しますか（これはサービス内で行います）呼び出し）、実際の保存を実行しますか？

CommandHandlerアプローチについて聞いたことがありますが、これは良いアプローチですか？理想的には、コントローラーアクションではなく、ドメイン内の単純なアプローチを使用して、検証と永続性を保持したいと思います。

ドメインモデルを使用しようとするアプリケーションに取り組んでいます。アイデアは、ビジネス ロジックをドメイン モデルのオブジェクト内に保持することです。現在、オブジェクトが関連オブジェクトをサブスクライブして、それらの変更に反応することで、多くのことが行われています。これは、PropertyChanged および CollectionChanged によって行われます。これは、次の場合を除いて問題ありません。

複雑なアクション : 多くの変更をグループとして処理する必要がある場合 (個々のプロパティ/コレクションの変更ではありません)。トランザクションを「構築」する必要がありますか / どのようにすればよいですか?

永続性: 永続性のために NHibernate を使用します。これは、クラスのパブリック プロパティ セッターも使用します。NHibernate がプロパティにアクセスすると、多くのビジネス ロジックが実行されます (これは不要に思えます)。NHibernate にカスタム セッターを使用する必要がありますか?

全体として、ドメイン モデルにすべてのロジックをプッシュすると、ドメイン モデルがかなり複雑になるようです。何か案は？？？

これが「サンプル」の問題です（私が使用している安っぽいツールで申し訳ありません）：

Project my コンテナとその下のオブジェクトがサブスクライブすることで相互に反応していることがわかります。現在、ネットワークへの変更は NetworkEditor を介して行われますが、このエディターは NetworkData の知識がありません。このデータは、場合によっては別のアセンブリで定義されることもあります。フローは、user->NetworkEditor->Network->NetworkData および関連する他のすべてのオブジェクトから進みます。これはスケールしないようです。

ドメインモデルをプレゼンテーションモデルに一般的にマッピングする方法を理解しようとしています。たとえば、次の単純なオブジェクトとインターフェイスが与えられた場合...

このようなコードを書けるようになりたいです...

...「MapperObject」は、2つのオブジェクト間でどのプロパティがマップされ、どのような種類のオブジェクトがマッピングされているかを、リフレクションや規則ベースのマッピングなどを使用して自動的に把握できます。したがって、同じように簡単に試すことができます。 UserPresentationModelやUserなどのオブジェクトを同じMapperObjectでマップします。

これは可能ですか？もしそうなら、どのように？

編集：わかりやすくするために、現在使用している非ジェネリックMapperObjectの例を次に示します。

私はまだこれを単一の製品ではなくリストで機能させる方法を模索していますが、それは別のトピックです:)

1 つの推薦者を割り当てることができるストーリーがあります。指名者は複数のストーリーに割り当てることができます。推薦者は、ストーリーを自分の投票に移すことができます (ストーリーは推薦者の投票にのみ属することができるわけではありません)。私は過去にデータ駆動型のアプリをずっとやっていたので、残念ながら投票の処理方法についてはすでに考えています。Story テーブルには nominator id が割り当てられているため、IsBallot フラグをテーブルに追加するのは理にかなっています。しかし今、私の実際のドメイン設計では、ストーリーはそれ自体を投票に追加する動作をしています (これには指名者に関連付けられたルールがあるため、これは奇妙に思えます)。投票に自分自身を追加できるかどうか、指名者に尋ねることができると思います。2 番目のオプションは、指名者 ID とストーリー ID を含む別のテーブル StoryBallot を用意することです。

どんなアイデアや提案も素晴らしいでしょう！

この種のデザインパターンを持つために私が取り組んでいるプロジェクトの1つは、1つのBeanがjsp / action / serviceクラスによって定義および使用されます。つまり、プレゼンテーションおよびビジネスロジックレイヤーによって使用され、別のBeanが定義および使用されます。 「エンティティ」と呼ばれるDAOレイヤーは、これら2つのBeanの内容に関係なく、実質的に同じです。JavaEEデザインパターンでは、各レイヤーを分離するために2つのBeanを使用する必要があると言われています。デカップリングについて私が理解していることは、クラスのワークフローとクラス階層によって実装されますが、データフローの場合、同じBeanを使用するのは簡単でスムーズであり、DAOレイヤーにPOJOを導入する理由の1つはこの変換がスムーズであることを確認してください。このデータフローを分離することで得られるメリットと、データフローで同じBeanを使用することで得られるデメリットについての専門知識を共有してください。