DDD

組織がモノリシック アーキテクチャからマイクロサービスに移行するとき、サービスの境界線をどのように引くかという、一か八かの重大な問題に直面します。 理論的には、マイクロサービスは、独立して開発、デプロイ、スケーリングできる、緩やかな分離されたユニットである必要があります。しかし、実際には、多くのチームが 分散モノリス を構築することになります。これは、サービスが非常に密接に結合されているシステムであり、1 つのビジネス変更で複数のサービスを同時に変更および展開する必要があり、ネットワーク遅延と展開の行き詰まりが悪化します。 この落とし穴を避けるために、ソフトウェア アーキテクトは ドメイン駆動設計 (DDD) に注目します。 2003 年に Eric Evans によって初めて導入された DDD は、コード構造をそれが表す複雑なビジネス ドメインに適合させるソフトウェア開発方法論です。 この記事では、クリーンで分離された、保守性の高いマイクロサービスを設計するための戦略的および戦術的な青写真を DDD がどのように提供するかを見ていきます。 1. 戦略的青写真: サービスの境界線を引く DDD は、戦略設計 と 戦術設計 という 2 つの主なフェーズに分かれています。戦略的設計とは、ビジネス コンテキストをモデル化し、サービスの境界を定義することです。アーキテクチャの「マクロ」ビューを提供します。 A. ユビキタス言語 企業内では、異なる部門が同じ言葉をまったく異なる意味で使用します。たとえば: 営業チームにとって、「ユーザー」は見込み客または潜在的な顧客です。 セキュリティ チームにとって、「ユーザー」はログイン資格情報のセットです。 配送チームにとって、「ユーザー」は物理的な受信者の住所です。 すべての人を満足させる「ユーザー」向けの単一の統合データベース モデルを構築しようとすると、大規模で複雑なコードベースが作成されます。 DDD は、ユビキタス言語 (特定の境界内でビジネス ドメインの専門家と開発者の両方によって定義および使用される共有語彙) を確立することでこの問題を解決します。