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

次のように定義されたデータベーススキーマがあるとします。 Person.mail_address_key ----- Address.address_key Person.billing_address_key ----- Address.address_key A Personには郵送先住所と請求先住所があります。非正規化手法として、別のAddressテーブルを作成します。時間のほとんどは、mail_address_keyおよびbilling_address_key単一のはPerson同じ値になります（例：自分の郵送や請求先住所のキーが同じになります）。 私のデータベースでAddressは、IDがあります（アドレスキー）。しかし、私のドメインモデルではAddress、がエンティティになる説得力のある理由はわかりません。値オブジェクトにしたいのですが。 DDDでは、これはオプションですか？または、値オブジェクトは通常、（テーブルではなく）列のグループですか？データベースがドメインモデルの構造を指示するべきではないと思うので、ここでは悪魔の擁護者を演じています。 もしそうなら、アドレスはどこで/いつ/どのようにデータベースのアイデンティティを失うので、ドメインレイヤーの値オブジェクトとして使用できますか？または、データベース識別子を値オブジェクトに保持することになっていますか？ モデルをデータベースに永続化する必要がある場合、プロセスは何ですか？私はa）これらのフィールドでアドレスを検索し、b）存在しない場合は新しいアドレスを作成しますc）存在する場合はフィールドを更新しますか？

8 domain-driven-design  domain-model  value-object 

ドメインモデルファクトリを実装する方法と場所を理解しようとしています。Company集計を、それをどのように行ったかのデモとして含めました。 私は最後に私の設計決定を含めました-それらの点に関するコメント、提案、批評をいただければ幸いです。 Companyドメインモデル： public class Company : DomainEntity, IAggregateRoot { private string name; public string Name { get { return name; } private set { if (String.IsNullOrWhiteSpace(value)) { throw new ArgumentOutOfRangeException("Company name cannot be an empty value"); } name = value; } } internal Company(int id, string name) { Name …

8 design  domain-driven-design  domain-model  architectural-patterns 

私のチームは、IDEに統合されるドメイン固有言語（DSL）のコンパイラを作成しています。現在、私たちはコンパイラーの分析フェーズに集中しています。リアルタイムのパフォーマンスと非常に詳細なエラー/警告/メッセージ情報が必要なため、既存のパーサージェネレーター（ANTLRなど）は使用していません。我々は持っています 各クラスは、言語の具体的な構文ツリーのノードを表します。 各ノードの注釈として機能するクラス（つまり、エラーや追加情報）、および 具体的な構文ツリー（つまり、レクサー、パーサー、文字列のキャッシュ、構文ビジター）を構築および操作する内部クラス。 テストを整理するための全体的な戦略を決定しようとしています。当社は、行動主導型開発（BDD）とドメイン主導型設計（DDD）を推進しています。弊社のドメイン用にDSLを構築していますが、コンパイラのドメインはプログラミング言語です。 私たちはまだコンパイラーを構築中であり、すでにいくつかのテストを行っています。100％ステートメントカバレッジを目指しています。 現在、構文ツリービルダーにソースコードを入力し、結果の構文ツリーのすべてのノードの各プロパティで検証を実行して、期待される情報（行番号、関連するエラー、子/親トークン、トークンの幅、トークンのタイプなど）。ここで、各ノードは独自のクラスであり、ノードに添付された特定の注釈とエラーは個別のクラスであるため、このテストは多くのクラスを参照することになります。 現在、入力（文字列）と出力（トークンのリスト）を他のクラス（構文ツリーのノードのクラスなど）から分離できるレクサーなどの特定のクラスのテストがあります。これらのテストはより詳細です。 これで、すぐ上の段落のテストを、テスト中のクラス（レクサー、文字列キャッシュなど）に対応させることができます。ただし、上記の2番目の段落のテストは、コンパイラーの分析フェーズ全体を実際にテストします。つまり、入力ソースコードが与えられている場合、各テストは構文ツリーに対して300以上のアサーションを持つことができます。テストは、分析フェーズの動作のためのものです。 これは適切なテスト戦略ですか？そうでない場合、私たちは何を別の方法で行うべきですか？テストにはどのような組織戦略を使用する必要がありますか？

8 unit-testing  compiler  domain-driven-design  bdd 

一部のエンティティを値オブジェクトに変換しようとすると、値オブジェクトが集約内で一意でなければならない場合に行き詰まります。 集約のルートを作成するMovieエンティティがあるとします。このMovieエンティティは、特定のタイムスタンプで広告を表示する役割を持ついくつかのAdvertisementEventオブジェクトのセットに関連付けられています。 AdvertisementEventはいくつかへのリンクが含まバナーが表示されている必要があり、座標といくつかの効果フィルタを。 以来AdvertisementEventだけで設定パラメータのコレクションを、私はそのアイデンティティを気にしてばかり大きな値オブジェクトのように扱う必要がある場合、私はわかりません。ただし、映画内では、特定のタイムスタンプで、おそらくタイムスタンプの前後でも、AdvertisementEventが1つだけであることを気にします。 私は疑問を複数の独立した質問に分割するのが難しいので、そこに行きます： ない設定パラメータのコレクションは、値オブジェクトのように聞こえますか？ 映画内のAdvertisementEventの一意性の概念とトランザクション整合性ルールを混在させていますか？ ない任意の時点での選択肢（2）のがあることを意味AdvertisementEventがで作られた集合体のメンバーでなければなりません作品？ 私のあるAdvertisementEventのオブジェクトは、エンティティ、値オブジェクトやイベントオブジェクト？（私の混乱を強調するために、名前にイベントサフィックスを使用しました） このような大きな値のオブジェクトはデザインのにおいですか？ 私はそれだけで何かではないので、私はDDDの意味でのイベントはお取り扱い致しておりませんことを推測起こります。実際のDDDイベントは、AdvertisementEventReachedのようなものでなければなりません。

8 domain-driven-design  entity  value-object 

C＃を使用した.NETドメイン駆動設計：問題-設計-解決策を読んだところ、作成者が各集計ルートのドメインサービスを作成していることに気付きました。 ただし、ドメインサービスは対応するリポジトリのファサードにすぎませんでした。たとえば、これは彼の本のアプリケーションのコードサンプルです。 public static class CompanyService { private static ICompanyRepository repository; private static IUnitOfWork unitOfWork; static CompanyService() { CompanyService.unitOfWork = new UnitOfWork(); CompanyService.repository = RepositoryFactory.GetRepository<ICompanyRepository, Company>(CompanyService.unitOfWork); } public static IList<Company> GetOwners() { return CompanyService.GetAllCompanies(); } public static IList<Company> GetAllCompanies() { return CompanyService.repository.FindAll(); } public static void SaveCompany(Company company) { CompanyService.repository[company.Key] …

8 java  c#  design  object-oriented  domain-driven-design 

私はDDDに不慣れで、貧弱なモデルのトランザクションスクリプトアプリ、または単にBig Balls of Mudでのみ働いていたので、私が乱用した用語を許してください。 ドメインモデルとリポジトリの適切な分離を理解しようとしています。（信じられないほど単純化された）オブジェクトをステータス（戻り値enumerable）またはIDでクエリする必要があると仮定して、データベースからのドメインオブジェクトを構築する適切な方法は何ですか。 ファクトリはオブジェクトを構築し、DIedリポジトリを使用してメソッドを公開する必要がGetByStatus()ありGetByID()ますか？ DTOからドメインモデルを構築する方法を知っていて、リポジトリを直接呼び出す必要がありますか？ ドメインモデルには、IDによる取得用のコンストラクターがあり、DIedリポジトリを使用して初期状態をロードし、リストに他の（？）メソッドを使用する必要がありますか？ 私は最善の方法が何であるか本当にわかりません、そしてこの質問はそれぞれを擁護する答えを持っています（これらは確かに相互に排他的です）。

8 design-patterns  domain-driven-design 

1つのサービス内に2つのリポジトリを持つ方法は正しいですか？それはアプリケーションまたはドメインサービスですか？ Passport（政府ID）オブジェクトを含むべきPassengerオブジェクトがあるとします。PassengerRepositoryからPassengerを取得しています。PassengerRepositoryはサーバーへのリクエストを作成し、受信したデータを解析してリポジトリ内に保存するよりもデータ（json）を取得します。 PassportをEntityとして保存してPassportRepositoryに置きたいのですが、パスワードに関するすべての情報に、上記で受け取ったものよりもjsonの内部が含まれているため、混乱しました。 removePassport, addPassport, getAllPassengerなどのいくつかのメソッドでPassengerRepositoryとPassportRepositoryを含むPassengerServiceを作成する必要があると思います。 更新： したがって、より良い方法はPassportをVOとして表し、すべてのパスポートをPassenger集約内に格納することだと思います。ただし、別の質問があります。管理乗客のパスポートのメソッド（メソッドはサーバーAPIを呼び出す）をどこに置くべきですか。乗客の集合体のほうがいいと思います。

8 design  design-patterns  object-oriented  architecture  domain-driven-design 

多くのスレーブエンティティで構成されるマスターと呼ばれるエンティティがあります。 データベースに存在できるマスターは1つだけであり、リポジトリーを照会して、指定されたIDのスレーブを取得します。 最初にSlaveRepositoryを作成し、それをIDでクエリしました。それは問題なく機能し、他の開発者が私のリポジトリを使用できます。 次に、集約ルートについて考え、MasterRepositoryを作成してマスターを返し、それに対してループを実行して、必要なスレーブエンティティを取得しました。私がここで感じた問題は、これを他の開発者に公開すると、同じようにする必要があるため、GetSlaveByID（string id）と呼ばれるMasterRepositoryのメソッドを使用して、スレーブを直接取得できます（ループ機能を非表示にします） ）。 さて、私のリポジトリはMasterRepositoryと呼ばれていてもスレーブを返す必要がありますか？そしてもっと重要なのは、どちらが正しい道なのか？ 私はDDDとTDDを適用しようとする初期段階にあるので、どちらが正しい方法であるかを判断する前に、おそらく多くのことを検討する必要があります。

8 architecture  tdd  domain-driven-design