タグ付けされた質問 「domain-model」

この用語は、ソフトウェアアーキテクチャ（「ドメインモデル」、「ドメインドリブンデザイン」など）のコンテキストでよく見られます。私はそれをグーグルで調べましたが、さまざまな定義がたくさんあります。それで、それは本当に何ですか？

104 domain-driven-design  terminology  domain-model  domain-objects 

ビジネスロジックの委任とカプセル化の境界はどこにありますか？委任すればするほど、貧血になります。ただし、委任は再利用とDRYプリンシパルも促進します。それでは、委任するのに適切なものと、ドメインモデルに残すべきものは何でしょうか？ 例として、次の懸念事項を取り上げます。 認証。ドメインオブジェクトは、そのアクセス制御ルール（CanEditプロパティなど）を維持する必要がありますか、それともアクセスの管理のみを行う別のコンポーネント/サービス（IAuthorizationService.CanEdit（object）など）に委任する必要がありますか？それとも、2つの組み合わせにする必要がありますか？おそらく、ドメインオブジェクトには、実際の作業を実行するために内部IAuthorizationServiceに委任するCanEditプロパティがありますか？ 検証。上記と同じ議論は検証に関するものです。誰がルールを維持し、誰がルールを評価する責任がありますか？一方では、オブジェクトの状態はそのオブジェクトに属している必要があり、有効性は状態ですが、すべてのドメインオブジェクトのルールを評価するために使用されるコードを書き直したくありません。我々は可能性があり、この場合の継承を使用して... オブジェクトの作成。ファクトリクラスとファクトリメソッド、インスタンスの「更新」。別のファクトリクラスを使用する場合、作成ロジックを分離してカプセル化できますが、オブジェクトの状態をファクトリに開くことを犠牲にします。これは、ファクトリが使用する内部コンストラクターを公開することでドメインレイヤーが別のアセンブリにある場合に管理できますが、複数の作成パターンがある場合は問題になります。そして、すべてのファクトリーが適切なコンストラクターを呼び出している場合、ファクトリーを持つことのポイントは何ですか？ クラスのファクトリメソッドは、オブジェクトの内部状態を開く問題を排除しますが、静的であるため、別のファクトリクラスの場合のように、ファクトリインターフェイスの注入によって依存関係を解除することはできません。 永続性。ドメインオブジェクトがCanEditを公開し、承認チェックを実行する責任を別の関係者（IAuthorizationService）に委任する場合、同じことを行うドメインオブジェクトにSaveメソッドがないのはなぜでしょうか。これにより、オブジェクトの内部状態を評価して、カプセル化を中断せずに操作を実行できるかどうかを判断できます。もちろん、リポジトリオブジェクトをドメインオブジェクトにインジェクトする必要がありますが、これは少し気になりますが、代わりにドメインイベントを発生させ、ハンドラーが永続化操作を実行できるようにしますか？ これでどこに行くのかわかりますか？ Rockford Lhotkaは、CSLAフレームワークのクラスインチャージルートに進む理由について素晴らしい議論をしており、そのフレームワークには少し歴史があり、ドメインオブジェクトと並行するビジネスオブジェクトの彼のアイデアをさまざまな方法で見ることができます。しかし、良いDDDの理想にもっと忠実になろうとしているので、コラボレーションが過剰になりすぎるのではないかと思っています。 集約ルートのIAuthorizationService、IValidator、IFactory、およびIRepositoryで終わる場合、何が残っていますか？オブジェクトの状態をDraftからPublishedに変更するPublishメソッドを使用して、クラスを非貧血ドメインオブジェクトと見なすのに十分ですか？ あなたの考え？

90 domain-driven-design  domain-model 

私は、電子工学の高度な技術であるためにドメインを理解するのが本当に難しい会社で働いていますが、これは複雑なドメインでのソフトウェア開発に適用できます。 私が取り組んでいるアプリケーションには、ドメインでの経験がなければ理解が難しい多くの情報、グラフ、およびメトリックが表示されます。開発者は、特定のチャートにこの種のメトリックを表示する必要があることを指定するなど、ソフトウェアが何をする必要があるかを記述する仕様を使用します。このメトリックは次の算術式です。 この方法では、開発者は実際にビジネスと彼がこのタスクを行っている理由を理解していません。仕様が非常に詳細な場合でも問題ありませんが、仕様が詳細でない場合、または作成者がユースケースを忘れた場合、開発者が解決策を見つけるのは非常に困難です。 一方、すべての開発者をすべてのビジネス面でトレーニングすることは非常に長く困難な場合があります。 詳細な仕様をもっと重視する必要がありますか（しかし、私たちが知っているように、完全な仕様は存在しません）、またはビジネスドメインを理解するようにすべての開発者を訓練する必要がありますか？ 編集：会社は外部の開発者を使用でき、すべてのドメインの編成は約2週間になる可能性があることを念頭に置いてください

52 domain-model  training 

ドメイン駆動設計とRESTの両方をサービス指向アーキテクチャに適用しようとしているプロジェクトに取り組んでいます。100％REST準拠について心配する必要はありません。リソース指向のHTTP API（〜RichardsonのREST成熟度モデルのレベル2）を構築しようとしていると言った方が良いでしょう。それでも、RPCスタイルのHTTPリクエストの使用は避けようとしています。つまり、例えば、POSTdo を使用するのではなく、RFC2616に従ってHTTP動詞を実装しようとしますIsPostalAddressValid(...)。 ただし、これに重点を置くことは、ドメイン駆動設計を適用しようとする試みを犠牲にしているようです。だけではGET、POST、PUT、DELETEおよびその他のいくつかのほとんど使用されない方法で、私たちは汚いサービスを構築する傾向があり、そして汚いサービスは、貧血のドメインモデルを持っている傾向があります。 POST：データを受信し、検証し、データにダンプします。GET：データを取得して返します。実際のビジネスロジックはありません。また、サービス間でメッセージ（イベント）を使用しますが、ビジネスロジックのほとんどは最終的にその周りに構築されるように思われます。 RESTとDDDは何らかのレベルで緊張していますか？（または、ここで何かを誤解していますか？他の何か間違っているのでしょうか？）RPCスタイルのHTTP呼び出しを回避しながら、サービス指向アーキテクチャで強力なドメインモデルを構築することは可能ですか？

34 rest  domain-driven-design  domain-model 

新しいシステムを設計する際に、誰かの名前を考慮すべきであり、人の名前を1つのフィールドとして保存するか、名/姓として別々に保存する必要がありますか？ 単一フィールドの長所： シンプルなUI 非常に長い名前を持つ人の名前を入力しようとしてもあいまいさはありません（多くの場合、姓/名であることが明らかではありません。） タイトルを処理する際の複雑さの軽減（「MD」または「Dr.」を入力するための別のフィールドは不要です） スプリットフィールドの長所： パーソナライズされたコミュニケーションは可能です「Dear Mr X」または「Dear Julie」 消費されたWebサービスが姓/名を個別に必要とする場合、簡単に提供できます。 厳格な身元確認要件のある業界（医療、政府など）に適した選択肢 常に単一フィールドの代替に戻ることができるため、より安全な選択 あなたはどのご覧ください追加の上に一覧表示されていない引数を？ 更新：問題は、ソリューションごとにどの追加（=質問にリストされていない）引数をリストできるかです。賛否両論の可能性の代わりに意見を述べることは、議論を間違った方向に進めると思います。各開発者はこの問題について決定する必要があります。この質問の目的は、必要に応じて評価できる重要な引数のリストを作成することです。

32 database-design  data  domain-model  data-modeling 

私は、個人、ユーザー、サービス、クーポン、署名パッケージなどの商業データなど、スタートアップ企業のすべてのサービスの一般的な非機能要件として使用されるデータベースをモデリングしています。 私は性別モデルについて考えています。これらの現代では、主観的なアイデンティティに関する国ごとに異なる法律があるので、それを考慮に入れて、男性と女性のオプション以外の個人エンティティをモデル化する必要がありますか？ オプションは、未定義、未回答、その他、トランスジェンダー...または私が知らないその他の業界標準です... それとも、LGBTの人々は本当に男性でも女性でもないと言って不快になりますか？

27 database-design  domain-model  data-modeling 

私は最近、原始的な強迫観念をコードの匂いとして説明する記事をたくさん読みました。 原始的な強迫観念を回避することには2つの利点があります。 ドメインモデルをより明確にします。たとえば、郵便番号を含む文字列ではなく郵便番号についてビジネスアナリストと話すことができます。 すべての検証は、アプリケーション全体ではなく1か所で行われます。 いつコードの匂いがするかを説明する記事がたくさんあります。たとえば、次のような投稿コードのプリミティブな強迫観念を取り除くことの利点を見ることができます。 public class Address { public ZipCode ZipCode { get; set; } } ZipCodeのコンストラクタは次のとおりです。 public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } 郵便番号が使用されるすべての場所にその検証ロジックを置くDRY原則を破ることになります。 ただし、次のオブジェクトについてはどうですか： 生年月日：気づきよりも大きく、今日の日付よりも小さいことを確認します。 給与：ゼロ以上であることを確認します。 DateOfBirthオブジェクトとSalaryオブジェクトを作成しますか？利点は、ドメインモデルを説明するときにそれらについて話すことができることです。ただし、これは多くの検証がないため、オーバーエンジニアリングの場合です。いつ、いつ原始的な強迫観念を取り除くべきでないかを説明するルールはありますか、可能であれば常にそれを行うべきですか？ クラスの代わりに型エイリアスを作成できると思います。これは上記のポイント1に役立ちます。

22 c#  domain-driven-design  domain-model  abstraction  modeling 

タスクログシステムがあるとします。タスクがログに記録されると、ユーザーはカテゴリを指定し、タスクはデフォルトで「未処理」のステータスになります。このインスタンスでは、CategoryとStatusをエンティティとして実装する必要があると想定しています。通常、私はこれをします： アプリケーション層： public class TaskService { //... public void Add(Guid categoryId, string description) { var category = _categoryRepository.GetById(categoryId); var status = _statusRepository.GetById(Constants.Status.OutstandingId); var task = Task.Create(category, status, description); _taskRepository.Save(task); } } エンティティ： public class Task { //... public static void Create(Category category, Status status, string description) { return new Task …

14 architecture  domain-driven-design  repository  domain-model  entity 

私はほぼ2年間ドメインドリブンデザインについて読んでおり、日々の仕事にいくつかの概念を慎重に導入するか、少なくともドメインドリブンデザイン内で定期的に行うことができる方法の計画を立てています。 特に、ドメインオブジェクトは書き込み目的にのみ使用されることを意図しているイベントソーシングとコマンドクエリの責任分離（CQRS）についての詳細を読んで、私が始めた結論の1つです。より明確にするために、私が読んだドキュメントの多くで人々が微妙に示唆していることは、ドメインオブジェクトがドメイン中心の操作/計算、検証を行う責任があること、そして主に永続化への道を提供するためにそこにあることを示唆しているようですリポジトリ実装内で提供されるインフラストラクチャ。状態を公開する責任を排除するため、これによりドメインモデルが大幅に簡素化される可能性があるという事実は気に入っていますが。 ドメインオブジェクトが主に書き込み専用オブジェクトとして使用されることが実際に正しい場合は、誰かに答えられることを望んでいるという疑問が生じます。 セッターを持つオブジェクト、またはオブジェクトの状態を変更するがC＃のプロパティゲッターなどから状態を読み取る外部へのパブリックインターフェイスを提供しないメソッドで単体テストを実行するにはどうすればよいですか？そのオブジェクトをテスト可能にするためだけに状態を公開しても大丈夫ですか？ ドメイン内で行われた計算または操作の結果を、それらを永続化せずにユーザーに表示し、ドメインのコンテキスト外の永続化ストアから結果をプルするにはどうすればよいですか？結果を表示するためだけに状態を公開しても大丈夫ですか？ 唯一のプロパティゲッター（getアクセサー）はドメインでも書き込み可能なものでなければならないという経験則ですか？または、読み取り専用プロパティは読み取り専用であり、実際のドメインモデルで必要な役割を果たさないため、読み取り専用プロパティは避けるべき唯一のものであると言いますか？ 関連資料： TDD、DDD、およびカプセル化

13 domain-driven-design  domain-model  cqrs  event-sourcing 

永続性無知は、単一の責任原則のアプリケーションです。実際には、ドメインオブジェクト（DO）に永続性に関連するコードを含めるべきではなく、ドメインロジックのみを含める必要があります。 a）これは、下位層（つまり、永続層）に接続するコードが、ビジネスロジック層の他のクラス（OC）のドメインモデルの外側にあることを意味すると思いますか？ b）の下で、私の仮定した場合）正しいこと、そしてDOたとえば、Customer、決してなどの方法が含まれていませんGetCustomersかGetCustomerByID？ c）a）およびb）の下での私の仮定が正しく、Customerドメインオブジェクトがそのプロパティの一部に遅延読み込みを使用すると仮定すると、ある時点でCustomer内部ロジックがOCに連絡し、次にOCが遅延データを取得する必要があります。しかし、遅延データを受け取るためにOCCustomerに連絡する必要がある場合、ドメインオブジェクトに永続性に関連するロジックが含まれていないことを主張することはできません。 ありがとうございました jkohlheppへの返信 1）クラスはビジネスロジック層に含まれているOrderProviderと思いCustomerProviderますか？ 2）b）の下での私の仮定が正しいというあなたの返事から集めますか？ 3） ...いくつかの非公開注文フィールドが入力されているか、それがヌルであるかを確認します。nullの場合... しかし、私が知る限り、ドメインコードがプライベートorderフィールドに入力されているかどうかを確認する必要があるとすぐに、もしそうでない場合はOrderProviderに問い合わせると、すでにPIの原則に違反していますか？！

12 design-patterns  domain-driven-design  domain-model  persistence 

私はドメイン駆動設計（DDD）の概念に飛び込んでいますが、特にドメインと永続性モデルの分離に関して、いくつかの原則が奇妙であることに気付きました。これが私の基本的な理解です： （機能セットを提供する）アプリケーション層のサービスは、その機能を実行するために必要なリポジトリからドメインオブジェクトを要求します。 このリポジトリの具体的な実装は、それが実装されたストレージからデータをフェッチします サービスは、ビジネスロジックをカプセル化するドメインオブジェクトに、その状態を変更する特定のタスクを実行するように指示します。 サービスは、変更されたドメインオブジェクトを永続化するようリポジトリに指示します。 リポジトリは、ドメインオブジェクトをストレージ内の対応する表現にマップする必要があります。 さて、上記の仮定を考えると、以下は厄介なようです： 広告2 :: ドメインモデルは、ドメインオブジェクト全体（すべてのフィールドと参照を含む）をロードしているように見えます。それを要求した関数には必要ない場合でもです。他のドメインオブジェクトが参照されている場合は、それらのドメインオブジェクトとそれらが参照しているすべてのオブジェクトを順にロードしない限り、完全にロードすることさえ不可能かもしれません。遅延読み込みが思い浮かびますが、これは、最初にリポジトリの責任であるドメインオブジェクトのクエリを開始することを意味します。 この問題を考えると、ドメインオブジェクトをロードする「正しい」方法には、各ユースケースに専用のロード関数があるようです。これらの専用関数は、それらが設計されたユースケースで必要なデータのみをロードします。ここで、ぎこちないことが出てきます。最初に、リポジトリの実装ごとにかなりの量のロード関数を維持する必要があり、ドメインオブジェクトはnull、フィールドを運ぶ不完全な状態になってしまいます。後者は、値がロードされなかった場合でも、それを要求した機能によって要求されるべきではないため、技術的には問題になりません。それでも厄介で潜在的な危険です。 広告3 :: ドメインオブジェクトは、リポジトリの概念がない場合、構築時に一意性の制約をどのように検証しますか？たとえばUser、一意の社会保障番号（指定されている）を使用して新しいを作成する場合、データベースに一意性制約が定義されている場合にのみ、リポジトリにオブジェクトの保存を要求すると、最も早い競合が発生します。それ以外の場合はUser、指定された社会保障でを探し、それが存在する場合は、新しいものを作成する前にエラーを報告できます。ただし、制約チェックはサービスに存在し、それらが属するドメインオブジェクトには存在しません。私はドメインオブジェクトが検証のために（注入された）リポジトリを使用することが非常によく許可されていることに気づきました。 広告5 .: 私は、ドメインオブジェクトのストレージバックエンドへのマッピングを、ドメインオブジェクトが基になるデータを直接変更するのと比較して、作業集約的なプロセスとして認識しています。もちろん、具体的なストレージ実装をドメインコードから切り離すことは、必須の前提条件です。しかし、それは確かにそのような高コストで来るのでしょうか？ ORMツールを使用してマッピングを行うオプションがあるようです。ただし、ORMの制限に従ってドメインモデルを設計する必要がある場合や、ドメインからインフラストラクチャレイヤーへの依存関係を導入する必要がある場合もあります（たとえば、ドメインオブジェクトでORMアノテーションを使用するなど）。また、私はORMがかなりの計算オーバーヘッドをもたらすことを読みました。 ORSQLのような概念がほとんど存在しないNoSQLデータベースの場合、ドメインモデルで変更されたプロパティをどのように追跡しますsave()か？ 編集：また、リポジトリがドメインオブジェクトの状態（つまり、各フィールドの値）にアクセスするためには、ドメインオブジェクトがカプセル化を解除する内部状態を明らかにする必要があります。 一般に： トランザクションロジックはどこに行きますか？これは確かに永続化に固有のものです。一部のストレージインフラストラクチャは、トランザクションをまったくサポートしない場合もあります（インメモリモックリポジトリなど）。 複数のオブジェクトを変更する一括操作の場合、オブジェクトのカプセル化された検証ロジックを通過するために、各オブジェクトを個別にロード、変更、および保存する必要がありますか？これは、データベースに対して単一のクエリを直接実行することとは対照的です。 このトピックについて、いくつかの説明をお願いします。私の仮定は正しいですか？そうでない場合、これらの問題に取り組む正しい方法は何ですか？

12 domain-driven-design  domain-model  persistence 

私はクリーンについて研究しており、その結果、ソフトウェアの設計と作成の方法について、かなり劇的に再考しています。 しかし、私がまだ取り組んでいることは、「一部のアイテムへの更新の保存時、最初の読み込みなど、表示/編集する権限のあるアイテムのすべてのリスト、このアイテムがリストにあることを確認するなどのビジネスルールです。そして、アイテムカテゴリは現在使用できないようにロックされていません（および他のルールなど） "。それは（複雑だが非定型ではない）ビジネスルールであり、ビジネスロジックをプッシュするのではなく、アプリケーションドメインで処理する必要があるためdb / persistenceレイヤー。 ただし、これらの条件を効率的にチェックするには、すべてのデータをアプリケーションドメインにロードするのではなく、巧妙に作成されたdbクエリで処理するのが最善のようです... 時期尚早な最適化なしで、推奨されるアプローチまたはこの質問を扱っているボブおじさんの記事は何ですか？または、「問題になるまでドメインで検証する」と言いますか？ 最も基本的な使用例以外の良い例やサンプルを見つけるのに苦労しています。 更新： みなさん、こんにちは。返信ありがとうございます。私はもっ​​と明確で、長い間（主にWebアプリ）のソフトウェアを書いていて、まとめて記述したすべてのトピックを確実に経験して同意しているはずです（バックエンドで検証し、クライアントデータを信頼せず、一般的に言って）必要な場合にのみ生の効率を追跡しますが、利用可能な場合はdbツールの強みなどを認識し、「まとめて投げる」という開発者の学習ライフサイクルを経て「N層アプリケーションで巨大な脂肪コントローラーを構築する」コードのトレンド、そして今は基本的にクリーンで単一の責任のスタイルなどを非常に気に入って調査しています。最近のいくつかのプロジェクトの結果として、プロジェクトが進化し、クライアントの要件がさらに明らかになるにつれて、非常に不格好で広く分散したビジネスルールに発展しました。 特に、クライアント向けのREST APIと内部使用機能のためのREST APIを構築するコンテキストでクリーンスタイルアーキテクチャを検討しています。この場合、ビジネスルールの多くは、ネットで目にするすべての例よりもはるかに複雑になる可能性があります。（Clean / Hexアーキテクチャの開発者自身によっても）。 だから私は、CleanとREST APIがどのように共存するかについて本当に質問しました（そして明確に述べられなかった）と思います、ここで最近見られるほとんどのMVCには受信リクエストバリデーターがあります（たとえば。 「検証」ルールはそれほど「50文字未満の文字列ですか」ではなく、「このユーザーは、このユーザーケース/インタラクターを呼び出して、関連するオブジェクトが現在チームXによってロックされている場合、このデータのコレクションに対してこの操作を実行できますか？」月末までなど」...ビジネスドメインオブジェクトやドメインルールが多数適用される、非常に複雑な検証。 これらのルールを特定の種類のValidatorオブジェクトタイプにスピンアウトして、各ユースケースインタラクター（FluentValidatorプロジェクトからインスピレーションを得たものの、より多くのビジネスロジックとデータアクセスを伴う）に付随させる必要があります。それらの検証をゲートウェイ（間違っていると思います）などに配置します。 参考までに、このようないくつかの記事を書きますが、Mattiaは検証についてあまり説明していません。 しかし、私の質問への短い答えは、私が受け入れた答えに非常に似ていると思います：「それは決して簡単なことではなく、それは依存します」。

12 clean-code  domain-model  validation  business-rules 

ビジネスロジックでは、次のようなメソッドが定義されている場合があります。 User.ResetCourse(Course courseToReset) 問題は、ユーザーとコースの両方がEntity Frameworkプロキシオブジェクトであるということです。つまり、ユーザーまたはコースのいずれかのナビゲーションプロパティにヒットすると、それらのオブジェクトはIQuery可能ではないため、通常どおりに繰り返されるため、データベースに大きなヒットを引き起こす可能性があります。 これを解決するために、署名を次のように変更しました。 User.ResetCourse(MyDBContext db, Course courseToReset) つまり、データベースに直接クエリを実行して必要な変更を効率的に行うことができますが、データベースコンテキストをビジネスオブジェクトに渡すことは非常に間違っているようです。 その後、ユーザーにサービスレイヤーを移行しました。つまり、次のようなものがあります。 CourseService.ResetForUser(Course courseToReset, User forUser) このサービスには、作成時に挿入されたDBContextへの参照がありますが、現在のビジネスオブジェクトは、動作のない単なるデータバッグです（つまり、Anemic Domain Model）。 どうすればこれを回避できますか？

11 c#  entity-framework  domain-model  business-logic 

質問の短い形式 エンティティメソッドの呼び出しにサービスを注入することは、DDDおよびOOPのベストプラクティスの範囲内ですか？ 長い形式の例 DDDに従来のOrder-LineItemsケースがあるとします。ここでは、Orderと呼ばれるドメインエンティティがあり、これは集約ルートとしても機能し、そのエンティティは値オブジェクトだけでなく、ラインアイテムのコレクションからも構成されます。エンティティ。 アプリケーションで流暢な構文を使用して、次のようなことができると仮定します（getLineItemsメソッドを呼び出す2行目の構文に注目してください）。 $order = $orderService->getOrderByID($orderID); foreach($order->getLineItems($orderService) as $lineItem) { ... } OrderEntityにLineItemRepositoryを挿入したくないのは、それが考えられるいくつかの原則に違反しているためです。しかし、構文の流暢さは私たちが本当に望んでいるものです。それは、テストだけでなく、読みやすく、保守しやすいからです。 のメソッドgetLineItemsに注意して、次のコードを検討してくださいOrderEntity。 interface IOrderService { public function getOrderByID($orderID) : OrderEntity; public function getLineItems(OrderEntity $orderEntity) : LineItemCollection; } class OrderService implements IOrderService { private $orderRepository; private $lineItemRepository; public function __construct(IOrderRepository $orderRepository, ILineItemRepository $lineItemRepository) { $this->orderRepository = $orderRepository; …

11 object-oriented  php  domain-driven-design  domain-model  lazy-initialization 

あなたは会社を追跡するシステムを構築しています。これらの企業には連絡先があります。これらの連絡先は、請求/支払い、販売、注文、カスタマーサポートなど、特定の種類の質問にのみ回答する専門家であることがよくあります。 ドメイン駆動設計とオニオンアーキテクチャを使用して、これを次のタイプでモデル化しました。 会社 連絡先あり 連絡先 連絡先タイプがあります ContactType（列挙型） CompanyRepository（インターフェース） EFCompanyRepository（外部アセンブリで定義、EntityFrameworkを使用、CompanyRepositoryを実装） 私たちのチームは、このアプリケーションのデータベースをモデル化する方法について意見が分かれています。 サイドA：リーンDDDers： 連絡先に有効なContactTypeを定義するのはドメインの仕事です。不明なContactTypesが保存されていないことを検証するためにデータベースにテーブルを追加することは、リークのあるドメインの兆候です。ロジックが広すぎます。 静的テーブルをデータベースと対応するコードに追加することは無駄です。このアプリケーションでは、データベースが1つの問題を解決します。問題を永続化し、それを私に返します。追加のテーブルと対応するCRUDコードを書くのは無駄です。 永続化の戦略を変更することは可能な限り簡単でなければなりません。そのビジネスルールを変更する可能性が高くなります。SQL Serverのコストが高すぎると判断した場合、スキーマに入力したすべての検証を再構築する必要はありません。 サイドB：伝統主義者[それはおそらく公平な名前ではありません。DBCentrists？]： コードを読み取らなければ意味のないデータをデータベースに置くことは悪い考えです。レポートやその他の消費者は、値のリスト自体を繰り返す必要があります。 オンデマンドでdbタイプの辞書をロードするためのコードはそれほど多くありません。心配しないでください。 このソースがデータではなくコードである場合、変更時に単純なSQLスクリプトではなくビットを展開する必要があります。 どちらも正しいか間違っているかではありませんが、そのうちの1つはおそらく長期的にはより効率的であり、初期開発、バグなどの開発時間を数えます。このスタイルのコードを書く他のチームは何をしますか？

10 domain-driven-design  domain-model  onion-architecture