問題タブ [ddd-service]

あなたの助けと注意を前もってありがとう！

私のプロジェクトは学習目的のみに専念しており、DDD と完全に混同しており、次のような状況にあります。

ユーザーとドキュメントが存在する私のドメインには、どこにでもある言語があります。次のように述べています。

私の質問を理解し、答えるにはこれで十分です。

User に CreateDocument(params)、SendDocumentForApproval(docId)、ApproveApprovalStepOfDocument(stepId) などのメソッドを含めることができるのは正常ですか?

コードが少し奇妙に見えるので、私は混乱しています。

たとえば、ドキュメント作成プロセスについては、次のようなものがあります。

承認プロセス:

私の考えをもっと詳しく説明したいと思います。ユーザーを見てみましょう。彼らは文書を管理します。ドキュメントはユーザーなしでは存在できません。ユーザーは、その集計を作成、更新、削除する必要があるため、集計ルートであることを意味しますか。

また、承認プロセスが含まれているため、ドキュメントは集約ルートでもあります。ApprovalProcess は、ドキュメントなしでは存在できません。

次のようなことをする必要があるということですか？

どうもありがとう、そして私のひどい英語でごめんなさい！よろしくお願いします

これは、現実の世界に影響を与える抽象的な質問です。

2 つのマイクロサービスがあります。CreditCardsServiceそれらをと と呼びましょうSubscriptionsService。

SubscriptionsServiceまた、顧客がサブスクライブできるように を使用することになっている SPA もあります。そのために、 にはサブスクリプション モデルでサブスクリプションを作成SubscriptionsServiceできるエンドポイントがあり、そのモデルでは、サブスクリプションの支払いが必要なクレジット カードをポイントします。サブスクリプションにクレジット カードを使用できるかどうかを示す特定のビジネス ルールがあります (有効期限が 12 か月以上先である、VISA であるなど)。これらの特定のビジネス ルールは、POSTcreditCardIdSubscriptionsService

問題は、SPA に取り組んでいるチームが、サブスクリプション モデルで使用できるユーザーのすべての有効なクレジット カードを返す/CreditCardsエンドポイントを必要とすることです。SubscriptonsService彼らは、SPA 自体にある同じビジネス検証ルールを SPA に実装したくありませんSubscriptionsService。

私には、これはマイクロサービス設計の中心である SOLID の原則に反しているように思えます。特に関心の分離。また、これはどのような前例となるでしょうか？OrdersService またはそのモデルのプロパティとして/CreditCards使用する可能性のあるその他のサービスにエンドポイントを追加する必要がありますか?creditCardId

主な質問はこれです: これを設計する最善の方法は何ですか? フロントエンドとバックエンドの間でビジネス検証ロジックを複製する必要がありますか? この新しいエンドポイントを に追加する必要がありSubscriptionsServiceますか? ビジネス ロジックを単純化する必要がありますか?

私は DDD を初めて使用するので、DDD の実装で直面しているいくつかの課題についてアドバイスをお願いします。

Typescript を使用してアプリケーションを開発しています。データはリレーショナル DB に永続化されます。私たちは CQRS パターンに従っておらず、読み取りと書き込みは同じデータベースで行われます。

Userおおよそ以下のような集計があると仮定しましょう。

ここではPhone、EmailはValueObjectsであり、AddressはEntityです。

クラスEmailも に似ていPhoneます。

ここで、電話の更新リクエストがコントローラーで受信されると、リクエストはUser Serviceレイヤーに転送され、サービスは大まかに次のようになります。

ここでは、ユーザーが電話番号の更新を要求するたびに、RDBMS からユーザー データを取得し、既に検証済みのすべてのフィールドに対してすべての検証を行ってから、メソッドを呼び出していUser.update()ます。だから、ここに私の質問があります：

1. 上記が正しい方法であるかどうかはわかりません。既に検証済みのものと、おそらく不要な DB 呼び出しを検証しているためです。そのため、このような単一または少数のフィールドの更新が要求されている状況に対処するためのベスト プラクティスを提案してください。
2. ユーザーは、他の情報とは関係なく自分の住所を更新できます。Addressでは、エンティティはAggregate Rootそれ自体である必要がありますか? はいの場合、単一の http 要求で UserInfo と Address の両方を更新するように要求された場合、どのように処理する必要がありますか?
3. 削除における集約ルートの役割は何ですか? それはその中でどのようにモデル化されるべきですか？

他にデザインの不具合等ありましたらご指摘ください。

ありがとう！