問題タブ [domain-driven-design]

最近のプロジェクトの仕様と機能要件について話し合っている間、チーム全体と顧客はすべてオランダ語を母国語としているため、オランダ語の会計用語についてドメインの専門家と話し合っていました。

開発が始まったとき、私たちはすべてのコードを英語で書いているので、ドメインクラスとインターフェースを英語で自然に実装しました。しかし、特に開発者が実装の詳細について話し合っていたために英語の用語を使用した場合、顧客とのフォローアップミーティングが混乱することがあることに気づきました。

これについてのあなたの経験は何ですか？

PS：Stack Overflowには、母国語でコードを書くべきかどうかについての投稿が他にもあることは知っていますが、この質問は、すべての開発者、顧客、ドメインの専門家が理解できるユビキタス言語の作成と使用に関するものです。

リポジトリ パターンを使用してトランザクション方式で複数のエンティティの保存をカプセル化するにはどうすればよいですか? たとえば、注文を追加し、その注文の作成に基づいて顧客ステータスを更新したいが、注文が正常に完了した場合にのみそうする場合はどうすればよいですか? この例では、注文は顧客内のコレクションではないことに注意してください。それらは独自のエンティティです。

これは単なる不自然な例であるため、注文が顧客オブジェクト内にあるべきかどうか、または同じ境界コンテキスト内にあるべきかどうかはあまり気にしません。基礎となるテクノロジ (nHibernate、EF、ADO.Net、Linq など) が使用されるかどうかはあまり気にしません。この明らかに不自然な操作の全か無かの例で、一部の呼び出しコードがどのように見えるかを確認したいだけです。

NHibernate では、ファクトリを使用して複雑な集約オブジェクト (エンティティ) を構築できますか? はいの場合、どのように？そうでない場合..その後、あなたのアプローチは何ですか?

How do you choose between implementing a value object (the canonical example being an address) as an immutable object or a struct?

Are there performance, semantic or any other benefits of choosing one over the other?

多くの製品/顧客/注文を含むデータベースがあり、コードベース (java/c#) にすべてのビジネス ロジックが含まれているとします。夜間には、データをフラット ファイルにエクスポートし、それらを独自のシステムに ftp するために、いくつかのバッチが必要です。

この「データベースをフラットファイルに書き込む」をどのように行うべきですか?ベストプラクティスは何ですか?

いくつかの考え：

• ストアド プロシージャを作成し、f.ex ssis を使用してデータをフェッチできますか? 「バッチ出力データベーステーブル」がある場合はこれを行うことができますが、ファイルが書き込まれる前にロジックを実行する必要がある場合はそうではありませんか?

• ドメインの残りの部分と同じリポジトリ/ビジネス ロジックを使用して、マネージド コードですべてのロジックを実行できますか? (これは、ストアド プロシージャ ソリューションに比べて処理が遅くなる可能性があります)

• ドメイン サービスの唯一のインターフェイスが Web サービス (各要求に「長い」時間がかかる可能性がある) である場合、「ベスト プラクティス」は変更されますか?

会社がまったく新しいアプリケーションを構築しているとしましょう。アプリケーションは DDD の原則に従っています。古いコードベースには、新しいコードベースに変換したい多くの製品 (または会社の別の「エンティティ」) があります。

この作業はどのように行うべきですか？通常、あるデータベースから別のデータベースへの転送など、ssis を使用してインポートする方が高速で簡単です。しかし、ここでの主な問題は、多くの BusinessRules (DomainLayer のマネージ コードに実装されている) がスキップされていることです...開発者が次のように言う場合、これで十分でしょうか:「私はそれを制御しています。ルールは SQL スクリプトとして複製されています.. ."

マネージ コード ライブラリを SQL Server にインポートする必要がありますか (少なくとも、.NET および MS SQL Server では可能です)。それとも、マネージド コードでインポート スクリプトを作成して、エンティティがデータベースに保存されるときにドメイン内のすべてのレイヤーがトラバースされるようにする必要がありますか?... (何時間もかかる可能性があります..)

あなたの考えは何ですか？

私はMVCアプリケーション用にいくつかのリポジトリを構築しており、リポジトリ間で責任を分担する正しい方法を考え出そうとしています。ほとんどの場合、これは明らかです。しかし、正しい答えが何であるかわからない特定のケースが1つあります。

このアプリケーションのユーザーは、従業員の複数のタイプの時間を追跡する必要があります。簡単にするために、2つだけを考えてみましょう。それらを「タイムカード」と「出席」と呼びます。これら2つの違いの正確な性質はそれほど重要ではありませんが、エンドユーザーはこれらを完全に別個のデータと見なしていることに注意してください。しかし、彼らがそれらを完全に別個のデータと見なす理由は、過去にそれらを一緒に見る機会が実際になかったからだと思います。どちらのタイプのレコードも、レコードの編集に関してほぼ完全に異なるビジネスルールを持っていますが、一般的に言えば、従業員が特定の時間にいた場所の両方のレコードでもあります。どちらのタイプの時間レコードにも、合計時間数など、多くの共通のプロパティがあります。と時間を収集した従業員。どちらのタイプにも、個々のタイプに完全に固有のいくつかのプロパティがあります。これらの「余分な」プロパティは、別のタイプのインスタンスに保持されています。したがって、一般的な構造は次のようになります。

したがって、問題は、ここで必要なリポジトリの数です。

1リポジトリ

リポジトリが1つしかない設計では、「タイムカード」、「出席」レコード、または両方のタイプを1つのリストに返すメソッドが公開されます。これはリポジトリのクライアントにとってはかなり便利ですが、私の考えでは、非常に太ったクラスになる危険性があります。「タイムカード」だけのリポジトリは、複雑なビジネスルールのせいで「出席」を処理しなくても、すでにシステム最大のリポジトリの1つになっていると思います。

2つのリポジトリ

別の設計には、「タイムカード」用の1つのリポジトリと、「出席」レコード用の別のリポジトリがあります。これには、たとえば「タイムカード」のビジネスルールがそれ自体で設定されているという利点があります。ただし、タイプに関係なく、すべての時間レコードのリストを取得する方法も必要です。この場合にどのリポジトリを使用するかは明確ではありません。両方？

3つのリポジトリ

「タイムカード」用の1つのリポジトリ、「出席」レコード用の別のリポジトリ、およびすべてのタイムレコードの読み取り専用リストを配信するための3番目のリポジトリを備えた設計も可能です。2リポジトリの設計と同様に、これには、たとえば「タイムカード」のビジネスルールがそれ自体で適切に配置されているという利点があります。結合されたリストをどこで入手できるかが明確になりました。しかし、2つの異なるリポジトリから同じレコードを取得できるのは少し奇妙だと思います。

ハイブリッド

ハイブリッドアプローチでは単一のリポジトリを使用しますが、ビジネスルールコード（レコードの選択を含む）を個別のタイプに移動します。この例では、単一の「タイムレコードリポジトリ」が「タイムカード」と「出席」時間のビジネスルール実装クラスのインスタンスを集約します。これが私が今好んでいるアプローチだと思います。

他の？

私が見逃したものはありますか？あるデザインを他のデザインよりも説得力のある議論はありますか？

ここにはかなり大きなアプリケーションがあり、DDD のガイダンスに従うために少しリファクタリングすることを検討しています。

今のところ、それに関する最大の問題は、境界付けられたコンテキストとコンテキスト マップです。多分私はそれを理解していないだけかもしれませんが、除算を行うことは不可能に思えます。たとえば、どこにでも User オブジェクトがあり、それはまったく同じ User オブジェクトです: 表示名、ID、役割。別の例があります。さまざまな場所の別のエンティティを分類するのに役立つ CatalogItem オブジェクトがあります。Bounded Context の依存関係を導入する必要がありますか? この厄介な電子商取引のサンプル以外に、この問題に関するガイダンスはありますか?

私は現在、最終段階のプロジェクトのコードをいくつかリファクタリングしていますが、多くのビジネス ロジックをドメイン オブジェクトではなくサービス クラスに配置することになりました。この時点で、ほとんどのドメイン オブジェクトはデータ コンテナーのみです。私は、ほとんどのビジネス ロジックをサービス オブジェクトで記述し、後ですべてをリファクタリングして、より再利用可能で読みやすい形にすることにしました。そうすれば、どのコードをドメイン オブジェクトに配置するか、どのコードを独自の新しいオブジェクトに分割するか、どのコードをサービス クラスに残すかを決定できました。だから私はいくつかのコードを持っています:

このコードは、ドメイン オブジェクト自体が唯一の入力パラメーターであるため、ドメイン オブジェクトに追加するのに適しているようです。いくつかのリファクタリングの完璧な候補のようです。しかし、唯一の問題は、このオブジェクトが別のオブジェクトのリポジトリを呼び出すことです。そのため、サービスクラスに残しておきたいと思います。

したがって、私の質問は次のとおりです。

1. このコードをどこに配置しますか?
2. この機能を分解しますか？
3. 厳密なドメイン駆動設計に従っている人は、それをどこに置きますか?
4. なんで？

御時間ありがとうございます。

編集注：これにはORMを使用できないため、遅延読み込みソリューションは使用できません。

編集注2:データレイヤーがリフレクションを使用してドメインオブジェクトをインスタンス化する方法のため、コンストラクターを変更してパラメーターを取り込むことはできません(私の考えではありません)。

編集注3:バッチオブジェクトがアプリケーションのリストを合計できるとは思いません。その特定のバッチにあるアプリケーションのみを合計できるように思われます。それ以外の場合は、関数をサービス クラスに残す方が理にかなっています。