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

私は最近、原始的な強迫観念をコードの匂いとして説明する記事をたくさん読みました。 原始的な強迫観念を回避することには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 

あるデータストアにきめ細かなデータを持ち、分析の大きな可能性を提供し、ビジネス価値を向上させ、必要に応じてパフォーマンスを向上させるために非正規化データを含む読み取りを必要とする柔軟性を備えているため、貧乏人のCQRS 1をかなり長い間適応させてきました。 しかし、残念ながら最初から、このタイプのアーキテクチャにビジネスロジックを正確に配置する必要があるという問題に苦労してきました。 私が理解していることから、コマンドは意図を伝える手段であり、ドメイン自体とは関係がありません。これらは基本的にデータ（ダム-必要に応じて）転送オブジェクトです。これは、異なるテクノロジー間でコマンドを簡単に転送できるようにするためです。同じことが、正常に完了したイベントへの応答としてイベントに適用されます。 典型的なDDDアプリケーションでは、ビジネスロジックはエンティティ、値オブジェクト、集約ルート内に存在し、データだけでなく動作も豊富です。ただし、コマンドはドメインオブジェクトではないため、データのドメイン表現に限定されるべきではありません。これは、コマンドに過度の負担をかけるためです。 本当の質問は、ロジックはどこにあるのでしょうか？ 値の組み合わせについていくつかのルールを設定する非常に複雑な集合体を構築しようとすると、私はこの闘争に最も頻繁に直面することがわかりました。また、ドメインオブジェクトをモデル化するときは、フェイルファーストパラダイムに従い、オブジェクトがいつメソッドに到達するかを知ることが有効な状態にあることを好みます。 集約Carが2つのコンポーネントを使用するとします。 Transmission、 Engine。 両方TransmissionとEngine値オブジェクトは、スーパータイプとして表され、サブタイプ、記載しているAutomaticとManualトランスミッション、またはPetrolとElectricそれぞれエンジン。 このドメインでは、それ自体で生活TransmissionするAutomaticかManual、成功するか、それとも、またはいずれかのタイプEngineが完全に作成されます。しかし、Car集約は該当する場合にのみ、いくつかの新しいルールを紹介Transmissionし、Engineオブジェクトが同じコンテキストで使用されています。すなわち： 車がElectricエンジンを使用する場合、許可されるトランスミッションタイプはのみですAutomatic。 車がPetrolエンジンを使用するとき、それはどちらのタイプも持つかもしれませんTransmission。 コマンドを作成するレベルでこのコンポーネントの組み合わせの違反をキャッチできましたが、前に述べたように、コマンドにはドメインレイヤーに限定されるべきビジネスロジックが含まれるため、実行すべきではないことを理解しているからです。 オプションの1つは、このビジネスロジック検証をコマンドバリデータ自体に移動することですが、これも正しくないようです。コマンドを分解し、ゲッターを使用して取得したプロパティを確認し、バリデーター内でそれらを比較して結果を検査しているように感じます。それは私にとってデメテルの法則違反のような叫びです。 上記の検証オプションは実行可能とは思えないため、破棄することは、コマンドを使用してそれから集計を構築する必要があるようです。しかし、このロジックはどこにあるべきでしょうか？具体的なコマンドを処理するコマンドハンドラー内にあるべきですか？それとも、おそらくコマンドバリデーター内にあるべきでしょう（このアプローチも好きではありません）。 現在、コマンドを使用しており、責任あるコマンドハンドラー内でコマンドから集計を作成しています。しかし、これを行うと、CreateCarコマンドが存在する場合、コマンドバリデータがまったく含まれないため、コマンドバリデータがあれば、別のケースで有効であることがわかっているコンポーネントが含まれますが、集計は異なると言う場合があります。 CreateUserコマンドを使用して新しいユーザーを作成する、さまざまな検証プロセスを組み合わせたさまざまなシナリオを想像してみましょう。 コマンドには、Id作成されたユーザーとそのが含まれますEmail。 システムは、ユーザーの電子メールアドレスについて次のルールを示します。 一意である必要があり、 空にしないでください、 最大100文字（db列の最大長）でなければなりません。 この場合、一意の電子メールを持つことはビジネスルールですが、システム内の現在の電子メールのセット全体をメモリにロードし、コマンドで電子メールをチェックする必要があるため、集約でチェックすることはほとんど意味がありません集合体に対して（Eeeek！何か、何か、パフォーマンス。）。そのため、このチェックをコマンドバリデータに移動します。コマンドバリデータはUserRepository、依存関係として受け取り、リポジトリを使用して、コマンドに電子メールが存在するユーザーが既に存在するかどうかをチェックします。 これに関しては、他の2つの電子メールルールをコマンドバリデーターに入れることは突然意味があります。しかし、ルールはUser集約内に実際に存在し、コマンドバリデーターは一意性のみをチェックし、検証が成功した場合は、User集約を作成CreateUserCommandHandlerしてリポジトリに渡し、保存する必要があると感じています。 リポジトリのsaveメソッドは、集約が渡されるとすべての不変条件が満たされることを保証する集約を受け入れる可能性が高いため、このように感じます。ロジック（空でないなど）がコマンド検証自体にのみ存在する場合、別のプログラマーはこの検証を完全にスキップUserRepositoryして、Userオブジェクトでsaveメソッドを直接呼び出すことができ、致命的なデータベースエラーにつながる可能性があります長すぎました。 これらの複雑な検証と変換をどのように個人的に処理しますか？私はほとんど自分のソリューションに満足していますが、選択肢にかなり満足するためには、私のアイデアとアプローチが完全に愚かではないことを断言する必要があると感じています。私は完全に異なるアプローチに完全にオープンです。個人的に何か試してみて、あなたのために非常にうまくいったことがあるなら、私はあなたの解決策を見たいと思います。 1 RESTfulシステムの作成を担当するPHP開発者として働いている私のCQRSの解釈は、コマンドを同期的に処理する必要があるためにコマンドから結果を返すことがあるなど、標準の非同期コマンド処理アプローチとは少し異なります。

22 domain-driven-design  business-logic  cqrs 

私のほとんどのプロジェクトでHibernateを約8年間使用した後、私はその使用を思いとどまらせ、ストアドプロシージャを介してのみDBと対話するアプリケーションを求めている会社に行きました。 数週間これを行った後、私が構築し始めているアプリケーションのリッチドメインモデルを作成することができず、アプリケーションは（恐ろしい）トランザクションスクリプトのように見えます。 私が発見した問題のいくつかは次のとおりです。 ストアドプロシージャは最小量のデータを読み込むだけなので、オブジェクトグラフをナビゲートすることはできません。つまり、フィールドが異なる類似したオブジェクトがある場合があります。たとえば、顧客からすべてのデータを取得するストアドプロシージャと、顧客からアカウント情報といくつかのフィールドを取得するストアドプロシージャがあります。 多くのロジックは最終的にヘルパークラスになるため、コードはより構造化されます（エンティティは古いC構造体として使用されます）。 ストアドプロシージャから結果セットを抽出し、エンティティに配置するフレームワークがないため、より退屈な足場コード。 私の質問は： 誰もが同様の状況にあり、ストアプロシージャアプローチに同意しませんでしたか？あなたは何をした？ ストアドプロシージャを使用する実際の利点はありますか？「誰もドロップテーブルを発行できない」という愚かな点は別として。 ストアドプロシージャを使用してリッチドメインを作成する方法はありますか？オブジェクトグラフをナビゲートできるように、AOPを使用してエンティティにDAO /リポジトリを挿入する可能性があることを知っています。ブードゥー教に非常に近いので、このオプションは好きではありません。 結論 まず、答えてくれてありがとう。私が到着した結論は、ORMは（一部の人が述べたように）リッチドメインモデルの作成を有効にしないが、（多くの場合繰り返し）作業の量を単純化するということです。以下は結論のより詳細な説明ですが、ハードデータに基づいていません。 ほとんどのアプリケーションは、情報を要求して他のシステムに送信します。これを行うには、モデル用語で抽象化（ビジネスイベントなど）を作成し、ドメインモデルがイベントを送受信します。通常、イベントにはモデルからの情報の小さなサブセットが必要ですが、モデル全体ではありません。たとえば、オンラインショップでは、支払いゲートウェイはユーザーに請求するためにユーザー情報と合計を要求しますが、購入履歴、利用可能な製品、およびすべての顧客ベースは必要としません。そのため、イベントには小規模で特定のデータセットがあります。 アプリケーションのデータベースを外部システムとして使用する場合は、ドメインモデルエンティティをデータベースにマッピングできる抽象化を作成する必要があります（NimChimpskyが言及したように、データマッパーを使用）。明らかな違いは、各モデルエンティティのデータベース（レガシースキーマまたはストアドプロシージャ）へのマッピングを手作業で作成する必要があることです。2つは同期していないため、1つのドメインエンティティが部分的にマッピングされる可能性がありますデータベースエンティティ（たとえば、ユーザー名とパスワードのみを含むUserCredentialsクラスが他の列を持つUsersテーブルにマップされる）、または1つのドメインモデルエンティティが複数のデータベースエンティティにマップされる場合があります（たとえば、1対1の場合テーブルに1つのマッピングがありますが、1つのクラスにすべてのデータが必要です）。 エンティティが少数のアプリケーションでは、エンティティを横断する必要がない場合、追加の作業量は少ないかもしれませんが、エンティティを横断する条件付きの必要がある場合は増加します（したがって、ある種の「怠lazな」読み込み」）。アプリケーションが成長してより多くのエンティティを持つようになると、この作業は増加するだけです（そして、非線形に増加すると感じています）。ここでの私の仮定は、ORMを再発明しようとしないことです。 DBを外部システムとして扱うことの利点の1つは、アプリケーションの2つの異なるバージョンを実行し、各アプリケーションのマッピングが異なる状況を回避できることです。これは、本番環境への継続的な配信のシナリオでより興味深いものになります...しかし、これは、ORMでもそれほどではないかもしれません。 開発者は、データベースにアクセスできなくても、悪意のあるコードを挿入するだけで、システムに格納されている情報のほとんどではなくてもほとんどを取得できることに基づいて、セキュリティの側面を無視します。親愛なる主よ、顧客のクレジットカードの詳細を記録する行を削除するのを忘れたとは信じられません！）。 小さな更新（6/6/2012） ストアドプロシージャ（少なくともOracleの場合）では、テーブルの構造を変更するとプロシージャとトリガーが無効になるため、ダウンタイムがゼロの連続配信のようなことはできません。したがって、DBが更新されている間、アプリケーションもダウンします。Oracleは、このためのEdition-Based Redefinitionと呼ばれるソリューションを提供しますが、この機能について私が尋ねた少数のDBAは、実装が不十分であり、運用DBに配置しないと述べました。

21 java  design  orm  stored-procedures  domain-driven-design 

複雑なビジネスドメインと、REST API（厳密にはRESTではなく、リソース指向）をサポートする要件を持つアプリケーションを設計しようとしています。リソース指向の方法でドメインモデルを公開する方法を考えるのに苦労しています。 DDDでは、ドメインモデルのクライアントは、手続き型「アプリケーションサービス」層を通過して、エンティティおよびドメインサービスによって実装されるビジネス機能にアクセスする必要があります。たとえば、ユーザーエンティティを更新する2つのメソッドを持つアプリケーションサービスがあります。 userService.ChangeName(name); userService.ChangeEmail(email); このアプリケーションサービスのAPIは、状態ではなくコマンド（動詞、プロシージャ）を公開します。 ただし、同じアプリケーションにRESTful APIも提供する必要がある場合は、次のようなユーザーリソースモデルがあります。 { name:"name", email:"email@mail.com" } リソース指向のAPIは、コマンドではなく状態を公開します。これにより、次の懸念が生じます。 REST APIに対する各更新操作は、リソースモデルで更新されているプロパティに応じて、1つ以上のアプリケーションサービスプロシージャコールにマップできます。 各更新操作は、REST APIクライアントにとってアトミックに見えますが、そのようには実装されていません。各アプリケーションサービス呼び出しは、個別のトランザクションとして設計されています。リソースモデルの1つのフィールドを更新すると、他のフィールドの検証ルールが変更される可能性があります。したがって、すべてのリソースモデルフィールドを一緒に検証して、潜在的なすべてのアプリケーションサービスコールが有効になるようにしてから、それらを作成する必要があります。一連のコマンドを一度に検証することは、一度に1つずつ実行することほど簡単ではありません。個々のコマンドが存在することすら知らないクライアントでそれをどのように行うのでしょうか？ アプリケーションサービスメソッドを異なる順序で呼び出すと効果が異なる場合がありますが、REST APIは違いがないように見えます（1つのリソース内） もっと似たような問題を思いつくかもしれませんが、基本的にはすべて同じことが原因です。アプリケーションサービスを呼び出すたびに、システムの状態が変化します。有効な変更のルール、エンティティが次の変更を実行できるアクションのセット。リソース指向のAPIは、すべてをアトミック操作のように見せようとします。しかし、このギャップを越える複雑さはどこかに行かなければならず、それは巨大なようです。 さらに、UIがよりコマンド指向である場合（多くの場合そうです）、クライアント側でコマンドとリソースをマッピングし、API側に戻す必要があります。 質問： このすべての複雑さを（厚い）RESTからAppServiceへのマッピングレイヤーで処理するだけですか？ または、DDD / RESTの理解に何か不足していますか？ RESTは、特定の（かなり低い）複雑度でドメインモデルの機能を公開するために、単に実用的ではないでしょうか？

20 architecture  rest  domain-driven-design 

アジャイル手法、ドメイン駆動設計、オブジェクト指向分析および設計など、ソフトウェア開発への多くのアプローチでは、開発への1つの反復アプローチを採用することをお勧めします。 そのため、プロジェクトでの作業を初めて開始したときにドメインモデルを正しく実行することは想定されていません。代わりに、時間が経つにつれてモデルをリファクタリングします。なぜなら、時間とともに問題の領域をより深く理解できるからです。 それとは別に、完璧なモデルを事前に取得しようとしても、私はすでに非常に難しいと確信していますが、要件は変わる可能性があります。ソフトウェアがそのようにした後にしている生産に配備され、エンドユーザーは、一定の要件を完全に理解していなかったことに気づくかもしれない、あるいは悪化し、いくつかの要件が欠落していました。 ここでのポイントは、ソフトウェアの展開後にモデルの変更が必要になる場合があるということです。これが発生した場合、問題が発生します。本番データベースには重要なユーザーデータがあり、古いモデルの形式に既に適合しています。 コードが適切に設計されておらず、システムが大きい場合、コードの更新は困難な作業になる可能性があります。しかし、それは時間とともに実行できます。Gitのようなツールを使用すると、本番対応バージョンを損傷することなくそれを実行できます。 一方、モデルが変更された場合、クラスのプロパティが消失した場合など、データベースも変更される必要があります。しかし、問題があります。そこには、失われないデータが既にあり、古いモデル用にフォーマットされています。 ここのリレーショナルデータベースは、エンドユーザーの要求に応じて反復的な開発を行ったり、ソフトウェアを更新したりすることを妨げる障壁になっているようです。 私がすでに使用したアプローチの1つは、古いデータベーステーブルを新しいテーブルにマップする特別なクラスをコーディングすることでした。したがって、これらのクラスは古い形式のデータを選択し、新しいモデルで使用される形式に変換して、新しいテーブルに保存します。 このアプローチは最良の方法ではないようです。ここでの私の質問は次のとおりです。リレーショナルデータベースで反復開発を調整するためのよく知られた推奨アプローチはありますか。

19 database  agile  domain-driven-design  relational-database  ooad 

貧血のドメインモデルは、 Martin Fowler氏によってドメイン駆動設計におけるアンチパターンとして記載されています。ドメインモデルでビジネスロジックを使用するには、多くの場合、ドメインサービスが使用されます。ただし、ドメインモデルへのドメインサービスの注入は、Vaughn Vernonにとって有害で​​あると考えられています（「ドメイン駆動設計の実装」を参照）。 私の意見では、これらの意見は矛盾している、これは本当ですか？両方のポイントをどのように考慮することができますか？ それは実際にされたドメインサービスと豊富なドメインモデルは、注入された対貧血のドメインモデルと通常のドメインサービス？

19 domain-driven-design  dependency-injection  services 

コマンドハンドラーを使用して永続性を処理するパターンは、IO関連のコードをできるだけ薄くしたい純粋に機能的な言語にどのように適合しますか？ オブジェクト指向言語でドメイン駆動設計を実装する場合、コマンド/ハンドラーパターンを使用して状態の変更を実行するのが一般的です。この設計では、コマンドハンドラーはドメインオブジェクトの上に配置され、リポジトリの使用やドメインイベントの発行など、永続性に関連する退屈なロジックを担当します。ハンドラーは、ドメインモデルのパブリックフェイスです。UIなどのアプリケーションコードは、ドメインオブジェクトの状態を変更する必要があるときにハンドラーを呼び出します。 C＃のスケッチ： public class DiscardDraftDocumentCommandHandler : CommandHandler<DiscardDraftDocument> { IDraftDocumentRepository _repo; IEventPublisher _publisher; public DiscardDraftCommandHandler(IDraftDocumentRepository repo, IEventPublisher publisher) { _repo = repo; _publisher = publisher; } public override void Handle(DiscardDraftDocument command) { var document = _repo.Get(command.DocumentId); document.Discard(command.UserId); _publisher.Publish(document.NewEvents); } } documentドメインオブジェクトは、（（「あなたは既に破棄されていた文書を破棄することはできません」または「ユーザーが文書を破棄する権限を持つべきである」のような）ビジネスルールを実装するため、我々は公開する必要があるドメインイベントを発生させるための責任があるdocument.NewEventsだろうIEnumerable<Event>おそらく含まれていますDocumentDiscarded）イベントを。 これは素晴らしいデザインです-拡張が簡単で（ドメインモデルを変更せずに新しいコマンドハンドラーを追加することで新しいユースケースを追加できます）、オブジェクトの永続化方法に依存しません（MongoのNHibernateリポジトリを簡単に交換できます）リポジトリ、またはRabbitMQパブリッシャーをEventStoreパブリッシャーに交換します）これにより、偽物やモックを使用して簡単にテストできます。また、モデル/ビューの分離に従います-コマンドハンドラーは、バッチジョブ、GUI、またはREST APIのいずれで使用されているかわかりません。 Haskellのような純粋に機能的な言語では、おおよそ次のようにコマンドハンドラーをモデル化できます。 newtype CommandHandler = CommandHandler {handleCommand :: …

18 c#  architecture  functional-programming  domain-driven-design  haskell 

DDDを使用するシステム（およびORMを使用するすべてのシステム）を検討してください。ほぼすべてのユースケースで、現実的にシステムのポイントは、これらのドメインオブジェクトを操作することです。それ以外の場合、実際の効果や目的はありません。 不変オブジェクトを変更すると、オブジェクトが永続化された後に新しいレコードが生成され、データソースに大量の膨張が発生します（変更後に以前のレコードを削除しない限り）。 不変オブジェクトを使用することの利点はわかりますが、この意味では、不変オブジェクトを使用する便利なケースはありません。これは間違っていますか？

18 immutability  domain-driven-design 

たとえば、登録フォームを送信するときは、有効な状態（例、電子メールアドレスの構文、年齢など）であることをDomain Model（WriteModelin CQRS）にチェックインする必要があります。 次に、を作成しCommand、それをに送信しますCommand Bus。 コマンドは何も返すべきではないことを理解しています。 では、エラーをどのように処理しますCommand Busか？（たとえば、1秒前に同じで登録したユーザーusername/email）。 そのコマンドが失敗したことをどのようにして知り、どのようにしてエラーを知っていますか？

17 domain-driven-design  error-handling  cqrs  error-detection 

私はVSでアプリケーションの構造を設定しようとしていますが、合理的なレベルに「試して」将来的に証明したいと思います。このアプリケーションは、慣例に従わなかった古いWinformアプリをWPFで書き直したものです。レイヤー、ティア、頭字語などはありません... これはかなり大規模なエンタープライズアプリケーションです。私のDBがそうであるように、Linq To SQLを使用する予定であり、ほとんどの場合、常にMS SQLになります。また、既存のスキルセットがあります。 できる限りMVVMとDDDをフォローしたいのですが、これらを組み合わせるとアプリケーションの構造が混乱します。いくつかの例を使って説明してみましょう。 MVVMに従うと、フォルダー構造は次のようになります。 Views Models ViewModels Helpers しかし、私のプロジェクト構造がこれに似ているかもしれない単純化されたDDD階層化アプローチにどのように適合しますか： MyApp.UI MyApp.Domain MyApp.Data Modelsドメインレイヤーに配置するのPersonですか、それともsayの3つのバージョンがありますか？これは、リポジトリとDBオブジェクトのドメインオブジェクトへのマッピングをどこに配置するかという別の質問につながりますか？私はデータを仮定します... Views私はUIに行くだろうが、ViewModelsまただろうか？ 最後に、ビジネスロジックをどこに埋め込むか。 CodePlex、DDD Exampleで以下を見つけましたが、いくらか助けになりましたが、Webアプリのように思えますが、それは問題ではなく、私の無知が輝いています。 誤解しないでください。フォルダをいくつでも持つことができ、好きな名前を付けることができます。私は、これらの場所が必ずしも呼ばれているものではなく、これがスケーラブルになるように、物を置く場所を見つけようとしています。 私の質問の核心はこのように示されるかもしれません。によって生成されたオブジェクト がありtblPersonます*.dbml。これは明らかであり、「データ」レイヤーに属します。 これで、Model、DTO、Domain Model、またはと呼ばれる別のLayer（project？）で呼び出されるものがありPersonます。私はどこに置くべきかわからないことのMapperためPersonに必要になるでしょうtblPerson。 次に、ViewModelをEditPerson取得しPersonます。たとえば、それから取得する独自のプロパティがありますが、それ以上の場合もあります。 最後に、そのViewModelにバインドされたビューがあります。 その段落が私の仮定と推測で満たされていることを明確にするために、誰かが私のために空気をきれいにするのを手伝うか、そこから洞察を提供してくれることを望んでいます。

17 .net  wpf  mvvm  domain-driven-design  project-structure 

グレッグヤングの講演7:20でDDD-Liteと呼ばれるものに言及したDDDプロジェクトが失敗する7つの理由に出会った。 要約すると、彼は基本的に、DDDに関連することを何もせずにパターン言語（エンティティ、リポジトリ、値オブジェクト、サービスなど）としてDDDを使用する人もいると言います。彼は、.Netのドメインモデルの60％以上がDDD-Liteであると仮定しています。彼は、DDD-Liteが基本的に依存性注入に関する言語を構築していると考えています。彼は、DDDを完全に実行するか、もっと簡単なことを行うと言います。そうでなければ、彼は、人が良い抽象化を構築するためにこの仕事のすべてを出しているが、本当の利益なしであると主張します。 私はDDDについてあまり知りたいとは思わないので、まだ使用しようとしていません。また、エリック・エヴァンの本も読んでいません。私はずっとエリック・エヴァンスDDD帳から、この主題の使用条件と参照概念に依存性の注入と、多くの、多くの書籍やブログに興味を持って。ここで、DDDの概念に触れました。私がこれを読んでいる本には以下が含まれます： .NETでの依存性注入 Microsoft .Net：企業向けアプリケーションの設計 .NETでのブラウンフィールドアプリケーション開発 依存性注入を実行したい場合、「DDD-Lite」を実行するより簡単な代替手段は何ですか？良い抽象化を構築することは、DDDの概念を「DDD-Lite」の方法で使用しているかどうかに関係なく、非常に役立つように思えます。（Mark Seemannのブログ投稿を参照してください。インターフェースは抽象化ではありません。より良い抽象化に向けて）。依存性注入を行っているすべての人が、本格的なDDDを実行している（または実行する必要がある）ことを信じるのは困難です。グレッグヤングのDDD-Liteについての議論を何らかの形で誤解しましたか？

17 .net  dependency-injection  domain-driven-design  abstraction 

最近、私はHohpeとWoolfのEnterprise Integration Patterns、Thomas ErlのSOAに関する本を読んでおり、Udi Dahanらによるさまざまなビデオやポッドキャストを見てきました。CQRSおよびイベント駆動型システム。 私の職場のシステムは、高い結合に悩まされています。各システムには理論的に独自のデータベースがありますが、それらの間には多くの結合があります。実際には、これは、すべてのシステムが使用する1つの巨大なデータベースがあることを意味します。たとえば、顧客データのテーブルが1つあります。 私が読んだことの多くは、各システムがデータベースのみを使用し、メッセージングを使用して他のすべてのシステムに更新が伝播されるように、データの非正規化を示唆しているようです。 これはSOAの境界を強化する方法の1つだと思いました-各サービスには独自のデータベースが必要ですが、それを読んでみました： /programming/4019902/soa-joining-data-across-multiple-services そして、これは行うのが間違っていることを示唆しています。 データベースを分離することは、システムを分離する良い方法のように見えますが、今は少し混乱しています。これは良いルートですか？SOAサービス、DDDバウンドコンテキスト、アプリケーションなどでデータベースを分離することをお勧めしますか？

17 soa  integration  cqrs  eai  domain-driven-design 

私は、数十のデータベーステーブル（集計、エンティティ/値オブジェクト）を使用する比較的複雑なアプリケーションで作業し、DDDを適用しています。この時点では、基本的にDDD-Liteのように見えます。つまり、アプリケーション/ドメインサービス、ドメインモデル（エンティティ、値オブジェクト）、およびリポジトリがあります。 私はDDDの実装という本を取り上げましたが、彼が最初に言及しているのは、DDDを開始するときによくある最初のミスとして、DDD-Liteおよびバウンドコンテキストとドメインイベントが欠落していることです。 現在、集計リレーションシップによってドメインモデルを整理し、ネームスペースを使用してそれを実証しようとしました。 ドメインモデルプロジェクトを個別のバウンドコンテキストに（まだ）分離することに関連する利点/欠点が見当たりません。おそらくそれは後で明らかになるかもしれませんが、バウンドコンテキスト（およびサブドメインなどが結び付けられている場合は、サブドメインなど）に関する実際のフィードバックをお願いします。

16 architecture  domain-driven-design  enterprise-architecture 

作業中の潜在的なプロジェクトを評価するとき、ドメイン駆動型の設計アプローチをそのオブジェクトモデルに使用することが有利である可能性があることを提案しました。プロジェクトには過度に複雑なドメインがないため、同僚がこれを投げました。 DDDは、複雑なドメインモデルがある場合に有利であると言われています（「...複雑で複雑なドメインで運用している場合は常に適用されます」Eric Evans）。 私が失ったものは-ドメインの複雑さをどのように定義するのですか？ドメインモデルの集約ルートの数で定義できますか？オブジェクトの相互作用におけるドメインの複雑さはありますか？ 私たちが評価しているドメインは、関連するオンライン出版とコンテンツ管理です。

16 complexity  domain-driven-design 

構成より規約を使用してdddアプリケーションを設計する方法を探しています。 集約「クライアント」に「FillProfile」と定義されたコマンドがあるとします。論理的に「ProfileFilled」イベントを発生させます。 コマンドがイベントよりも多く発生する場合、またはコマンドが何らかのロジックに基づいて異なるイベントを発生する場合がありますか？または、これは常に1対1の関係です（1つのコマンドは常に何も発生させないか、特定のタイプの単一のイベントを発生させます）。 これが事実である場合、コマンドが常に同じイベントを発生させるため、その事実に基づいてコンベンションシステムを構築できるため、これを求めています。「RaiseEvent」が「EventRaised」になることを知っています...

16 domain-driven-design  cqrs  event-sourcing