1. 構造とは
大まかに言うと、アーキテクチャは製品アーキテクチャとシステム アーキテクチャを含む組み合わせ構造であり、優れたアーキテクチャにより、製品とシステムがより適切に提示され、より適切に反復され、維持されるようになります。優れたアーキテクチャは進化し、優れたコードはリファクタリングされます。
ミドルプラットフォーム、プラットフォーム、システム、アプリケーションなどの名詞をよく聞きますが、これらはどのような関係があるのでしょうか？
1) アプリケーション: 最も小さな粒度であり、業務システムの機能を実現するために使用されます。例えば、現在はマイクロサービスが普及しており、業務システムを実現するアプリケーションにはWebアプリケーションやサービスアプリケーションが一般的です。
2) システム: ここで言及するシステムはすべて業務システムであり、一般に業務システムは少なくとも完全な商用製品です。調達システム、入札システムなど。
3) プラットフォーム：複数の業務システムから構成され、単一の業務システムよりも機能が豊富で、特定の分野において比較的完全な業務機能を提供します。例えば、調達プラットフォームは、ソーシングや入札などの業務システムから構成されます。このプラットフォームは機能再利用であり、通常は単一のシナリオのみをサポートします。たとえば、大企業の調達プラットフォームは大企業の調達のシナリオのみをサポートします。
4) ミドルプラットフォーム: プラットフォームをベースに、ビジネス再利用である拡張ポイントを通じて複数のシナリオがサポートされます。調達センターでは大企業、中小企業、個人の調達をサポートします。
各レベルには独自のアーキテクチャ (プラットフォーム アーキテクチャ、ビジネス システム アーキテクチャ、アプリケーション アーキテクチャ) があり、焦点も異なります。プラットフォーム アーキテクチャとシステム アーキテクチャでは、責任の分割境界、展開方法、新しいテクノロジー (クラウド アクセス、マイクロサービスなど) のアプリケーションにさらに注意が払われます。アプリケーション アーキテクチャは、アプリケーション自体の階層化と設計に重点を置いています。たとえば、現在では階層化アーキテクチャと DDD ドメイン駆動設計が一般的になっており、この記事ではアプリケーション アーキテクチャに焦点を当てます。
2. 責任分担
システム境界の分割はビジネス アーキテクチャにとって重要であり、一般原則は責任に応じた分割です。責任がどのドメインに割り当てられているかわからない場合は、中間ドメインを割り当てることができます。
ユース ケースを分析すると、同じドメイン内のモデルは頻繁に対話する必要があり、クロスドメイン モデルはほとんど対話しない必要があります。クロスドメイン モデルが頻繁に対話することがわかった場合は、ドメインの責任の分割に問題がある可能性があります。
3. ドメイン駆動設計とそのコアコンポーネント
ドメイン駆動設計の概要
ドメイン駆動とは何ですか? ドメイン駆動設計は、システムの設計と開発を導く考え方であり、ビジネス ドメインの知識に注意を払い、ドメインの知識を理解し、ドメイン指向とモデル指向であることが求められます。テクノロジー指向ではなく、データ指向のデザイン。ビジネスドメインの専門家との継続的なコミュニケーション、ドメイン知識の深い理解、システム設計の継続的な反復を通じて、より良いドメインモデルを提示します。価値のあるドメイン モデルはすぐに現れるものではなく、ドメイン知識を深く理解した後に取得する必要があります。
なぜドメイン設計が必要なのでしょうか? ソフトウェア システムの複雑さは、技術的な実装自体から生じるのではなく、ビジネス自体、複雑なビジネス プロセスや進化から生じることがよくあります。
ドメイン モデルは、技術専門家とビジネス専門家の両方が理解する必要があります。ドメイン専門家がドメイン モデルを理解できない場合は、モデルの設計が間違っていることになります。ドメイン モデリングには、エンティティの構築だけでなく、値オブジェクト、ドメイン サービス、実装パターンも含まれます。設計と実装は結合する必要があり、設計と実装を分離すべきではありません。ドメイン設計を見るときは、システムの実装モードを理解する必要があります。そうでないと、実装者はドメイン設計の意図を理解できず、システム実装がドメイン設計から逸脱するほど、ドメイン モデルのデータ整合性を保証することが難しくなり、ドメイン設計全体が無意味になってしまいます。
ドメイン モデルは、ドメインの中核概念を抽象化したものであるだけでなく、ソフトウェアの開発と実装をガイドすることもできます。オブジェクト指向設計は、ほとんどのドメイン モデリングに使用されるモデリング パラダイムです。
ドメイン コア コンポーネントには、ドメイン オブジェクトとドメイン オブジェクトのライフサイクル管理が含まれます。ドメイン オブジェクトには、エンティティ、値オブジェクト、ドメイン サービスが含まれます。ドメイン オブジェクトのライフサイクル管理には、ファクトリ、リポジトリ、集約が含まれます。ドメイン オブジェクトとドメイン オブジェクトのライフサイクル管理はどちらもドメイン層の中核資産です。
1) エンティティ: エンティティは独立して存在でき、ビジネス上の相互作用において意味を持ち、固有の記号の存在を必要とし、固有の記号は実際のビジネス上の意味を持ちます。たとえば、オンラインショッピングの場合、送られてくる荷物の中身は同じですが、別の荷物になります。
2) 値オブジェクト: 通常、コンテンツのみを考慮し、一意の識別子の必要性を考慮せず、エンティティの追加属性として集約を使用します。たとえば、人がブラシで絵を描くとき、どのブラシであるかではなく、ブラシの色、太さ、その他の特性のみを気にします。つまり、シーン内では、内容がまったく同じであれば、同じオブジェクトとみなされ、値オブジェクトとなり、それ以外の場合はエンティティとなります。
3) ドメイン サービス: ドメイン内で、エンティティや値オブジェクトに属さない特別な操作が行われることがあります。このとき、ドメイン サービスを使用できます。このとき、ドメイン サービスは、ドメインの概念を表す最良の方法です。ドメイン サービスのパラメータと戻り値は、ドメイン内のモデルである必要があり、サービスはステートレスである必要があります。
4) 集約: 集約とは、エンティティを集約ルートとして取り、他の値オブジェクトを属性として集約することです。集約ルートは変更/クエリの最小単位である必要があり、集約ルートを単位として変更/クエリを実行する必要があります。集約は一般にエンティティと値オブジェクトの間の関係を指し、関連付けは一般にエンティティ間の関係を指します。
5) ファクトリ: ファクトリの主な役割は、オブジェクトの作成とオブジェクトの再構築 (ストレージ メディアからクエリされたデータをドメイン オブジェクトに再構築する) です。複雑なオブジェクトの作成はドメイン層に属し、オブジェクト自体を通じて実現する必要はなく、ファクトリを通じて作成できます。ファクトリは通常、一般化が必要な複雑なオブジェクト タイプを作成するために使用され、単純なモデル オブジェクトはコンストラクターを通じて直接作成できます。
6) リポジトリ: オブジェクトとストレージ間の相互変換を主な役割とし、型を適切に抽象化できるため、各モデルがリポジトリに対応する必要はありません。
DDD アプリケーション アーキテクチャ レイヤ化のベスト プラクティス
1) 階層化されたアプリケーション アーキテクチャ
2) 商用能力
さまざまな分野 (場合によっては組織や部門全体) の機能を組み合わせることで、特定のビジネス機能を統合でき、構成 + カスタマイズによる素早いアクセスにより、ビジネスの反復を高速化できます。
4. ドメイン駆動設計の指針となるイデオロギー
1) ドメイン層では、ビジネス ロジックを表現するためにドメインの概念を使用する必要があり、すべてのコア ドメイン ロジックはドメイン コンポーネントに基づいて実装されます。外部実装に直接依存したり、無関係なインターフェイスを外部に公開したりする代わりに、ドメイン層を主要な保護オブジェクトにする必要があります。
2) リポジトリ層は通常、トランザクション制御には関与しません。
3) ドメイン モデルの設計と責任に常に注意を払い、オブジェクト指向設計の SOLID 原則を遵守し、ドメイン オブジェクトをデータ コンテナとしてのみ使用しないでください。
4) 値オブジェクトを直接走査する代わりに、集計ルートを介してデータベースを走査して、関連する値オブジェクトを見つけます。エンティティをスキップして値オブジェクトを直接走査する必要がある場合は、モデルの設計が不合理かどうか、および値オブジェクトをエンティティとして設計する必要があるかどうかを検討する必要があります。
5) パッケージデザインや分割も含め、全体のデザインは低結合かつ高凝集である必要があります。
6) ソフトウェア設計は常に複雑さと闘い、複雑な設計は本当に必要な場所に任せる必要があります。ドメイン モデリングは、関連付けを単純化することから始まります。モデル間の関連付けは、できるだけ複雑でないようにする必要があります。1 対多で関連付けられるものは多対多の関連付けとして設計しないでください。1 対 1 で関連付けできるものは 1 対多の関連付けとして設計しないでください。また、一方向で関連付けできるものは双方向であってはなりません。単純化できない場合は、関連付けの複雑さを軽減できる適切で現実的な条件を追加できないかどうかを検討してください。関連付けが複雑になればなるほど、データの一貫性を保証することが難しくなり、システムの安定性を保証することが難しくなり、システム実装の複雑さが増します。この関係を適切に単純化できれば、ドメイン知識の深い理解を反映することになります。制約された関連付けにより、より多くの知識が伝達され、より実用的になります。モデルの関連付けを慎重に単純化して制約することが、ドメイン駆動設計を実現する唯一の方法です。
7) エンティティと値オブジェクトのニーズに応じてデータ ストレージ構造を設計する 一般に、大きなフィールドが別のテーブルに分割されていない限り、1 対 1 のドメイン モデル関連情報はデータ テーブルに格納できます。1 対多のデータは、異なるテーブルにのみ分割できます。データベース設計では、データのクエリと更新をより効率的に行い、データの整合性をより安全に確保することを遵守する必要があります。
8)集約ルートを介して集約内の関連オブジェクトにアクセスすることに加えて、他の方法で集約内の他のオブジェクトにアクセスすることは許可されません。