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

ドメイン駆動設計（DDD）は、実装を進化するモデルに接続することにより、複雑なニーズに対応するソフトウェアを開発するためのアプローチです。

10
設計パターンにこれほど多くのクラスが必要なのはなぜですか？
私はシニアのジュニア開発者であり、彼らの思考や推論を理解することに苦労しています。 私はドメイン駆動設計（DDD）を読んでいますが、なぜこれほど多くのクラスを作成する必要があるのか​​理解できません。ソフトウェアを設計するその方法に従えば、最大で2つのファイルと3〜4の関数で置き換えることができる20〜30のクラスになります。はい、これは面倒な場合がありますが、ずっと保守しやすく読みやすいです。 ある種のEntityTransformationServiceImpl機能を確認したいときはいつでも、多くのクラス、インターフェース、それらの関数呼び出し、コンストラクター、それらの作成などに従う必要があります。 簡単な数学： 60行のダミーコードと10クラスX 10（このようなロジックはまったく異なるとしましょう）= 600行の乱雑なコードと100クラス+ラップして管理するためのその他のコード。依存性注入を追加することを忘れないでください。 乱雑なコードの600行を読み取る= 1日 100クラス= 1週間 誰もが簡単にメンテナンスできると言っていますが、何のためですか？新しい機能を追加するたびに、ファクトリ、エンティティ、サービス、および値を持つ5つのクラスを追加します。この種のコードの移動は、乱雑なコードよりもずっと遅いように感じます。 たとえば、1か月で50KのLOC乱雑なコードを記述する場合、DDDには多くのレビューと変更が必要です（どちらの場合もテストは気にしません）。1つ追加するだけで1週間以上かかる場合があります。 1年で多くの乱雑なコードを作成し、何度も書き換えることもできますが、DDDスタイルでは、乱雑なコードと競合するための十分な機能がまだありません。 説明してください。このDDDスタイルと多くのパターンが必要なのはなぜですか？ UPD 1：たくさんの素晴らしい回答を受け取りました。どこかにコメントを追加したり、リストを読むためのリンクを使って回答を編集してください（DDD、デザインパターン、UML、コード完了、リファクタリング、実用的） ..非常に多くの優れた書籍）、もちろんシーケンスを使用して、理解を開始し、一部の皆さんと同じようにシニアになることもできます。
5
これらのすべてのサービスで、どうすれば貧血にならないのですか？
ビジネスロジックの委任とカプセル化の境界はどこにありますか？委任すればするほど、貧血になります。ただし、委任は再利用とDRYプリンシパルも促進します。それでは、委任するのに適切なものと、ドメインモデルに残すべきものは何でしょうか？ 例として、次の懸念事項を取り上げます。 認証。ドメインオブジェクトは、そのアクセス制御ルール（CanEditプロパティなど）を維持する必要がありますか、それともアクセスの管理のみを行う別のコンポーネント/サービス（IAuthorizationService.CanEdit（object）など）に委任する必要がありますか？それとも、2つの組み合わせにする必要がありますか？おそらく、ドメインオブジェクトには、実際の作業を実行するために内部IAuthorizationServiceに委任するCanEditプロパティがありますか？ 検証。上記と同じ議論は検証に関するものです。誰がルールを維持し、誰がルールを評価する責任がありますか？一方では、オブジェクトの状態はそのオブジェクトに属している必要があり、有効性は状態ですが、すべてのドメインオブジェクトのルールを評価するために使用されるコードを書き直したくありません。我々は可能性があり、この場合の継承を使用して... オブジェクトの作成。ファクトリクラスとファクトリメソッド、インスタンスの「更新」。別のファクトリクラスを使用する場合、作成ロジックを分離してカプセル化できますが、オブジェクトの状態をファクトリに開くことを犠牲にします。これは、ファクトリが使用する内部コンストラクターを公開することでドメインレイヤーが別のアセンブリにある場合に管理できますが、複数の作成パターンがある場合は問題になります。そして、すべてのファクトリーが適切なコンストラクターを呼び出している場合、ファクトリーを持つことのポイントは何ですか？ クラスのファクトリメソッドは、オブジェクトの内部状態を開く問題を排除しますが、静的であるため、別のファクトリクラスの場合のように、ファクトリインターフェイスの注入によって依存関係を解除することはできません。 永続性。ドメインオブジェクトがCanEditを公開し、承認チェックを実行する責任を別の関係者（IAuthorizationService）に委任する場合、同じことを行うドメインオブジェクトにSaveメソッドがないのはなぜでしょうか。これにより、オブジェクトの内部状態を評価して、カプセル化を中断せずに操作を実行できるかどうかを判断できます。もちろん、リポジトリオブジェクトをドメインオブジェクトにインジェクトする必要がありますが、これは少し気になりますが、代わりにドメインイベントを発生させ、ハンドラーが永続化操作を実行できるようにしますか？ これでどこに行くのかわかりますか？ Rockford Lhotkaは、CSLAフレームワークのクラスインチャージルートに進む理由について素晴らしい議論をしており、そのフレームワークには少し歴史があり、ドメインオブジェクトと並行するビジネスオブジェクトの彼のアイデアをさまざまな方法で見ることができます。しかし、良いDDDの理想にもっと忠実になろうとしているので、コラボレーションが過剰になりすぎるのではないかと思っています。 集約ルートのIAuthorizationService、IValidator、IFactory、およびIRepositoryで終わる場合、何が残っていますか？オブジェクトの状態をDraftからPublishedに変更するPublishメソッドを使用して、クラスを非貧血ドメインオブジェクトと見なすのに十分ですか？ あなたの考え？
4
リッチドメインモデル—正確に、動作はどのように適合しますか？
リッチドメインモデルと貧血ドメインモデルの議論では、インターネットは哲学的なアドバイスに満ちていますが、権威のある例は不足しています。この質問の目的は、適切なドメイン駆動設計モデルの決定的なガイドラインと具体例を見つけることです。（理想的にはC＃で。） 実際の例では、このDDDの実装は間違っているようです。 以下のWorkItemドメインモデルは、Entity Frameworkがコードファーストデータベースに使用するプロパティバッグに他なりません。ファウラーごとに、それは貧血です。 WorkItemService層は、明らかにドメインサービスの一般的な誤解です。WorkItemのすべての動作/ビジネスロジックが含まれています。イェメリャノフなどによると、手続き型です。（ページ6） 以下が間違っている場合、どうすれば正しくできますか？AddStatusUpdateまたはCheckoutなど の動作はWorkItemクラスに属している必要がありますか？ WorkItemモデルにはどのような依存関係が必要ですか？ public class WorkItemService : IWorkItemService { private IUnitOfWorkFactory _unitOfWorkFactory; //using Unity for dependency injection public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) { _unitOfWorkFactory = unitOfWorkFactory; } public void AddStatusUpdate(int workItemId, int statusId) { using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) { var workItemRepo = unitOfWork.WorkItemRepository; var workItemStatusRepo = …
4
英語以外のドメインでのプログラミングとユビキタス言語（DDD）
このテーマに密接に関連する質問がすでにここにあることは知っていますが、ユビキタス言語を出発点とする質問はないので、この質問を正当化すると思います。 知らない人のために：ユビキタス言語とは、翻訳の問題や誤解による矛盾や誤解を避けるために、開発者とドメインの専門家の間で等しく使用される（話し言葉と書き言葉の両方の）言語を定義する概念です。同じ用語がコード、チームメンバー間の会話、機能仕様などに表示されます。 だから、私が疑問に思ったのは、英語以外のドメインでユビキタス言語に対処する方法です。 個人的には、コメントを含むが、もちろん定数とリソースを除く、完全に英語でプログラミングコードを書くことを強く推奨します。 ただし、英語以外のドメインでは、次のいずれかを決定する必要があります。 ドメインの自然言語でユビキタス言語を反映するコードを記述します。 ユビキタス言語を英語に翻訳し、ドメインの自然言語でのコミュニケーションを停止します。 ユビキタス言語の英語への翻訳方法を定義するテーブルを定義します。 これらのオプションに基づく私の考えのいくつかを以下に示します。 1）混合言語コード、つまり英語以外の型/メンバー/変数名などを使用してコーディングすることに対して強い嫌悪感を持っています。ほとんどのプログラミング言語は英語をかなり「呼吸」し、ほとんどの技術文献、デザインパターン名なども英語です。したがって、ほとんどの場合、英語以外の言語で完全にコードを記述する方法はないため、いずれにしても混合言語になります。 2）これにより、ドメインの専門家は、ULに相当する英語で考えて話し始めるように強制されます。 3）この場合、開発者は母国語でドメインエキスパートと通信し、開発者は互いに英語で通信します。最も重要なのは、ULの英語翻訳を使用してコードを書くことです。 私は最初のオプションに行きたくないと確信しており、オプション3はオプション2よりも優れていると思います。他のオプションがありませんか？ 更新 約1年後の今日、この問題を日常的に扱ってきたので、オプション3がうまく機能したと言わざるを得ません。 最初に恐れていたほど退屈ではなく、クライアントと話すこともリアルタイムで翻訳することも問題ではありませんでした。 私の経験に基づいて、次の利点があることもわかりました。 ULを翻訳すると、特に用語の翻訳方法がわからず、辞書などを調べ始める必要がある場合に、ULおよびドメイン自体の定義にさらに注意を払うことになります。何回か。 英語の知識をより深めるのに役立ちます。 明らかに、あなたのコードは、わいせつな気分になるのではなく、見るのがはるかに楽しいです。
5
エンドユーザーの命名法が変更された場合、コードとデータの名前をどこまで変更する必要がありますか？
かなり前に、ワークフローキューに追加された画像をユーザーが「受け入れる」機能を追加しました。結局、間違った用語を使用し、ユーザーは実際に画像を「承認」しました。 インターフェースのAcceptをApproveに変更するのは簡単です。1つの単語を置き換えるだけです。ただし、CSSクラス名からデータベース値まで、すべてのレイヤーを「accept」という単語でプログラミングしました。 ボタンを緑色にするCSSクラス： ".accepted"; DOMノードのクラス属性を検証およびバインドするモデルメソッド： "isAccepted"; JavaScriptステータス属性：「未確認」、「承認済み」、「公開済み」の配列。 Mysqlステータス列：「未確認」、「承認済み」、「公開済み」のENUM。 テスト名; 承認する承認のほとんどの出現を置き換えることは簡単です（特にテストがある場合）。特に、展開と同期する必要があるため、データを移行するのが少し難しくなります。 この特定のケースは単純ですが、私のキャリアの中で、同様の、さらに複雑なケースに直面しました。ファイルの名前も変更され、数十台のサーバーで展開が行われる場合、またはプロキシキャッシングの場合、memcachedとmysqlが関係します。 インターフェース以外のすべてのレイヤーに「受け入れられた」ままにしておくのは悪い考えです。チームに参加する新しいプログラマーは、この決定に至った歴史的な理由を学ばない可能性があるためです。 「管理上の次のステータス会議のためにキューに入れられました」に名前が変更されました、それは確かに意味をなさないでしょう。そして、あちこち妥協しても、ユーザーインターフェイスの概念はシステムの内部に影響を与えないことを何度か繰り返しますが、出力の半分が内部に接続されていないシステムで作業したくはありません。 だから、必要なときに常にすべての名前を変更していますか？これがあなたに起こり、トレードオフは価値がないと判断した場合、それはあなたを噛むために戻ってきましたか？この問題を回避するには、コードコメントまたは開発者向けドキュメントで十分ですか？
7
アプリケーション層vsドメイン層？
私はEvansによるドメイン駆動設計を読んでおり、階層アーキテクチャについて議論している部分にいます。アプリケーション層とドメイン層は異なり、別々にする必要があることに気付きました。私が取り組んでいるプロジェクトでは、それらは混ざり合っており、本を読むまで違いを伝えることはできません（そして、今では私にとって非常に明確だとは言えません）。 私の質問は、どちらもアプリケーションのロジックに関するものであり、技術的側面とプレゼンテーションの側面はきれいであると想定されているため、これら2つの境界線を引くことの利点は何ですか？
7
システムを100％データ駆動できますか？
私の上司は長年このプロジェクトに取り組んでいます。私はここに数週間しかいませんが、それが可能かどうかはわかりません。彼は「100％データ駆動型」のシステムを設計したいと考えています。 したがって、十分なデータを入力すれば、任意のアプリケーションを定義および生成できます。私は少なくともユーザーなどのいくつかのことを認めさせることができました、またはアプリには事前定義された値が必要ですが、彼はシステムの構造、ユーザーインターフェイス、ロジックがすべてデータとして保存されるという概念が好きです。 単純なもののデモがいくつかあり、彼は基本的にオブジェクト指向プログラミングと基本的なテンプレートシステムのいくつかの単純なアイデアを再発見しましたが、この目標は実際には不可能であると思います。 システムを非常に複雑にせずに実際のプログラミングを行うことなく、データを使用してロジックを定義する方法がわかりません。 理論的には、データを解釈するものがアプリケーションを説明するために完全にチューリングする必要があるので、問題を1レベル上にシフトしてネットメリットがないからではないと思います。 このような100％データ駆動型アプリケーションは可能ですか？
11
ドメインが豊富なアプリケーションでレポートおよびダッシュボード用のデータを取得するためのベストプラクティスまたは設計パターン
まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。 私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。 タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。 レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？ 私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。 例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。 総予算 これまでの努力 燃焼速度 現在の燃焼速度での予算枯渇日 等 これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に1つずつ、500の異なるレートのレートシートを適用し、費用や適切なマークアップなどを適用する必要があることですロジックは広範です。クライアントにとって妥当な時間内にこのデータを取得するには、多くの集約とクエリのチューニングが必要でした。 これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？単純なSQLクエリを使用しても、クライアントが妥当な時間内に表示するのに十分な速度でこのデータを取得することはほとんどありません。これらすべてのドメインオブジェクトをリハイドレートし、アプリケーションレイヤーでデータを混合および照合して集約する場合、またはアプリケーションでデータを集約しようとする場合、クライアントにこのデータを十分に速く取得しようとすることは想像できません。 これらのケースでは、SQLはデータの処理に優れているように思われますが、使用しないのはなぜですか？ただし、ドメインモデルの外部にビジネスロジックがあります。ドメインモデルおよびレポート集計スキームでビジネスロジックを変更する必要があります。 ドメイン駆動設計と優れた実践に関して、アプリケーションのレポート/ダッシュボード部分をどのように設計するかについて、私は本当に困っています。 MVCはデザインフレーバーデュジュールであり、現在のデザインで使用しているため、MVCタグを追加しましたが、レポートデータがこのタイプのアプリケーションにどのように適合するかわかりません。 本、デザインパターン、グーグルのキーワード、記事など、この分野での助けを探しています。このトピックに関する情報が見つかりません。 編集と別の例 今日出会った別の完璧な例。顧客が顧客営業チームのレポートを望んでいる。彼らは単純なメトリックのように見えるものを望んでいます： 各営業担当者の現在までの年間売上はいくらですか？ しかし、それは複雑です。各販売員は複数の販売機会に参加しました。勝った人もいなかった人もいます。各販売機会には、それぞれの役割と参加ごとに、販売に対するクレジットの割合が割り当てられた複数の販売員がいます。それでは、このためにドメインを通過することを想像してください。すべての営業担当者のデータベースからこのデータを引き出すために必要なオブジェクトの再水和の量： すべての取得SalesPeople- > それぞれが得るために彼らのSalesOpportunities- > 各販売の彼らの割合を取得し、その販売量を算出するために 、すべての彼らの最大の追加SalesOpportunity販売量を。 そして、それは1つのメトリックです。または、迅速かつ効率的に実行し、高速に調整できるSQLクエリを作成できます。 編集2- CQRSパターン CQRSパターンについて読んだことがありますが、興味深いことに、Martin Fowlerもテストされていないと言います。それで、過去にこの問題はどのように解決されましたか。これは、何らかの点で全員が直面していなければなりません。成功の実績を持つ確立されたアプローチまたは使い古されたアプローチとは何ですか？ 編集3-レポートシステム/ツール このコンテキストで考慮すべきもう1つのことは、レポートツールです。Reporting Services / Crystal Reports、Analysis Services、Cognoscentiなどはすべて、SQL /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？
8
ドメイン駆動型設計はアンチSQLパターンですか？
私はドメイン駆動設計（DDD）に飛び込んでいますが、さらに深く掘り下げていくと、得られないことがいくつかあります。私が理解しているように、主なポイントは、ドメインロジック（ビジネスロジック）をインフラストラクチャ（DB、ファイルシステムなど）から分離することです。 私が疑問に思っているのは、マテリアルリソース計算クエリのような非常に複雑なクエリがある場合、どうなりますか？この種のクエリでは、SQLが設計された種類の重いセット操作を操作します。ドメインレイヤー内でこれらの計算を行い、その中の多くのセットを操作することは、SQLテクノロジーを破棄するようなものです。 DDDパターンでは、ドメインレイヤーを変更せずにMongoDBにSQL Serverなどの同じ機能がないことを認識せずにインフラストラクチャを変更できるため、インフラストラクチャでこれらの計算を行うこともできません。 それはDDDパターンの落とし穴ですか？
3
DDDに関して、境界付きコンテキストとは何ですか？
Vaughn Vernon著の「Implementing Domain Driven Design」という本を読んでいると、境界のあるコンテキストが実際に何であるかをよく理解できませんでした。 この本は、境界付きコンテキストを「ドメインモデルが適用可能な概念的境界。チームによって話され、慎重に設計されたソフトウェアモデルで表現されるユビキタス言語を提供します」と定義します。この定義は、境界コンテキストがサブドメインのモデルと言語であるかのように聞こえます。そのサブドメインは、たまたまコアドメイン（「コアサブドメイン」と呼ばれるべきですが、それは別の議論...）。これは、境界付きコンテキストが提供するものに関して、まだいくつかのあいまいさを残しています。1つ以上のサブドメインのグループ化ですか？1つのサブドメインのみが境界付きコンテキストに対応している場合、境界付きコンテキストは実際に何を伝えていますか？ ただし、同じ本の第3章では、境界のあるコンテキスト間の統合手法について言及しています。ただし、これは、境界付けられたコンテキストが実際にはソフトウェアシステムまたはさまざまなアーティファクトであることを意味するように思われます。 Martin Fowlerは、境界のあるコンテキスト（http://martinfowler.com/bliki/BoundedContext.html）のアイデアについて簡単に説明しますが、実際には問題を明確にしません。 一日の終わりには、何である有界コンテキストは？サブドメインのグループ化ですか？サブドメインのモデルと言語？サブドメインの実装？これらの答えがなければ、現実の問題空間を境界のあるコンテキストに分解する方法を理解するのはかなり難しいようです。
6
DDD集計はWebアプリケーションで本当に良いアイデアですか？
私はドメイン駆動設計に飛び込み、私が出会う概念のいくつかは表面的にはかなり理にかなっていますが、それらについてもっと考えるとき、それは本当に良いアイデアかどうか疑問に思う必要があります。 たとえば、集計の概念は理にかなっています。ドメインモデル全体を扱う必要がないように、所有権の小さなドメインを作成します。 ただし、これをWebアプリのコンテキストで考えると、データベースに頻繁にアクセスして、データの小さなサブセットを取り戻します。たとえば、ページには注文の数だけがリストされ、クリックして注文を開いて注文IDを表示するリンクが表示されます。 私は右の理解集約だ場合、私は一般的にメンバーが含まれますOrderAggregateを返すために、リポジトリのパターンを使用することになりGetAll、GetByID、Delete、とSave。いいですね。しかし... GetAllを呼び出してすべての注文を一覧表示すると、このパターンでは、集計情報の一覧全体、注文全体、注文明細などが返される必要があるように思えます。その情報の小さなサブセットのみが必要な場合（ヘッダー情報のみ）。 何か不足していますか？または、ここで使用する最適化のレベルがありますか？必要のないときに情報の集合体全体を返すことを支持する人がいるとは想像できません。 確かに、リポジトリのようなメソッドを作成できGetOrderHeadersますが、そもそもリポジトリのようなパターンを使用する目的に反しているようです。 誰も私のためにこれを明確にすることはできますか？ 編集： さらに調査を重ねた結果、ここでの断絶は、純粋なリポジトリパターンが、ほとんどの人がリポジトリと考えているものと異なることだと思います。 Fowlerは、リポジトリをコレクションセマンティクスを使用するデータストアとして定義し、通常はメモリ内に保持されます。これは、オブジェクトグラフ全体を作成することを意味します。 Evansはリポジトリを変更して集約ルートを含めるため、リポジトリは切断され、集約内のオブジェクトのみをサポートします。 ほとんどの人は、リポジトリを栄光に満ちたデータアクセスオブジェクトと考えているようです。ここでは、必要なデータを取得するメソッドを作成するだけです。これは、ファウラーの「エンタープライズアプリケーションアーキテクチャのパターン」で説明されているような意図ではないようです。 さらに、リポジトリは、主にテストとモック作成を簡単にするため、または永続性をシステムの残りの部分から切り離すために使用される単純な抽象化と考えています。 答えは、これが最初に思っていたよりもはるかに複雑な概念であると思います。
5
関数型プログラミングの文脈で貧血モデルについて話すことはまだ有効ですか？
DDDの戦術的なデザインパターンのほとんどはオブジェクト指向のパラダイムに属し、貧弱なモデルは、すべてのビジネスロジックがオブジェクトではなくサービスに置かれ、一種のDTOになっている状況を表します。言い換えると、貧血モデルは手続き型の同義語であり、複雑なモデルにはお勧めできません。 純粋な関数型プログラミングの経験はあまりありませんが、DDDがFPパラダイムにどのように適合し、その場合に「貧血モデル」という用語がまだ存在するかどうかを知りたいです。 更新：Recentlry は、このテーマに関する本とビデオを公開しました。
2
マイクロサービスアーキテクチャで共有の概念をどのように処理しますか？
開発中のアプリケーションのアーキテクチャパターンを調査しており、マイクロサービスアプローチが適切な選択のように思えますが、サービス間の相互作用を処理する方法はわかりません。 このアプリケーションは主に、ユーザー、ユーザーが所有するプロファイル、写真、および写真内の1つから多数のプロファイルを表すタグを扱います。ユーザーがアップロードした写真を返す方法、特定のタグ付きプロファイルを含む写真を返す方法などが考えられます。 これはマイクロサービスベースのアーキテクチャを設計する最初の試みであり、モノリシックなドメインモデルに触発された歴史から来ています。その世界では、コントローラーはこれらのドメインオブジェクトをつなぎ合わせますが、これがマイクロサービスの方法でどのように機能するかについて頭を包むのに苦労しています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.