7

私は少し混乱しています。私は若い銀行会社で働いており、複雑さを解消するために DDD アーキテクチャを実装することにしました。

それで、ここに私の質問があります（チームの誰かが行った設計提案に従います）。3 つの異なるドメインがあるとします。ドメイン (Web) サービスを公開する D1、D2、D3。各ドメインは、同じテーブルに依存する厳密に型指定されたビジネス エンティティを操作します。これらのドメインの前では、テーブルに保持されているデータの一貫性を一元的に保証するマイクロサービスが必要です。D1、D2、および D3 は、特定のルールに従ってデータを永続化するようにマイクロサービスに要求します。マイクロサービスがテーブルへの CRUD プロキシとして機能するようにします。マイクロサービスは、D1、D2、および D3 ドメインに特定の DTO を提供し、テーブルを D1、D2、D3 に難読化します。

このアプローチはよさそうですか？DDD アーキテクチャでマイクロサービスを使用して、1 つ以上のドメインの CRUD とデータの一貫性を管理することを検討しますか? マイクロサービスを使用してデータを「CRUD」および検証すると、境界付けられたコンテキストが壊れますか? DDD アーキテクチャでマイクロサービスを扱う場合のベスト プラクティスは何ですか?

あなたの貢献に感謝します。

[編集]

次の記事は、私の考えを洗練するのに役立ちました: http://martinfowler.com/bliki/MicroservicePremium.html

マイクロサービスは、モノリシック システムの保守に失敗した複雑な状況で役立ちます。これらは、先行設計の実装には適していません。一方、DDD はプロジェクトの最初の段階で複雑さに取り組もうとします。成功する DDD は、マイクロサービスの実装に対応するべきではありません。

4

2 に答える 2

13

検証、計算、永続化 (CRUD) などはすべて関数であり、サービスではありません。これらのタスクを 1 つのサービスに集中させることで、他のすべてのサービスをそれに密結合させ、SOA の主な利点を失います。高い結束を維持しながらサービスを疎結合にすることが、主な目標です。このデザインはそれに違反しているように感じます。

サービスは、一元化された一般的なサービスやレイヤーではなく、関連するビジネス機能の垂直スライスとして設計する必要があります。サービスは、データベースから UI に至るまで企業全体に展開されるコンポーネントで構成されている必要があります。また、実用的でない場合は、各サービスに独自のデータベースまたは少なくともスキーマが必要です。データベースを共有するサービスがあるとすぐに、再び密結合になります。

最後に、サービスの 1 つが単純な CRUD 挿入を行う必要がある場合は、それだけで十分です。最初にドメイン モデルにマップする必要はありません。実際の不変条件を適用する必要があるビジネス プロセスには、DDD を保存します。オール オア ナッシングのアプローチである必要はありません。各ユースケースに適したツールを使用してください。

于 2015-04-15T02:53:31.303 に答える
6

マイクロサービスは、境界付けられたコンテキストを「壊す」ことは想定されていません。マイクロサービスと BC 境界の間には自然な相関関係があるため、マイクロサービスは補完的です。

テーブルに永続化されたデータの一貫性を一元化された方法で保証するマイクロサービスが必要です

マイクロサービスは、見せかけの目的でここにあるわけではありません。そして、それらはすべて中央集権化ではなく、非中央集権化に関するものです。これらは、ビジネス機能を中心に編成されたモジュラー ユニットです。これらは通常、 Domainの背後にある永続ストアへのプロキシではなく、 Domain の前にある境界コンテキストへのゲートウェイとして機能します。

問題に間違った解決策を適用しようとしているようです-マイクロサービスをデータ中心のモノリスへの収束ポイントとして使用すると、その目的全体が無効になります。

おそらく、「永続化されたデータの一貫性を保証する」および「特定のルールに準拠したデータを永続化する」という意味について詳しく説明する必要があります。永続化レイヤーまたはマイクロサービスではないサービスに実装されているだけかもしれません。

于 2015-04-15T08:57:54.113 に答える