問題 04: ドメイン駆動設計とマイクロサービス

ここに記録されているのは学習共有の内容であり、記事は Github: studeyang/leanrning-shareで管理されています。

ドメイン駆動設計を理解するには?

マイクロサービスの台頭により、ドメイン駆動設計 DDD (ドメイン駆動設計) という言葉を聞いたことがあると思いますが、用語として見ると少し抽象的です。これはなに？

心配しないでください。テスト駆動開発 (TDD、テスト駆動開発) について聞いたことがあるはずです。

このコンセプトは何ですか? つまり、開発プロセスではまずテストを行うべきであり、まずテストプログラムを書いてからそれを実現するコードを書くことが推奨されています。開発が目的で、テストは補助的であるため、テスト駆動開発と呼ばれますが、これを 3 つの用語に分解して理解する必要があります。

したがって、ドメイン駆動設計では、設計が目的であり、ドメインは補助的なものになります。ソフトウェアを設計したいのですが、業務が複雑すぎて設計が難しいです。このとき、ドメインのアイデアを使用して設計を支援します。

マイクロサービスはどれくらい小さくなければなりませんか?

あなたがビジネスアーキテクトだったら、設計プロセス中にどのような困難に遭遇すると思いますか? 最初に直面する疑問は、「マイクロサービスはどれくらい小さくすべきでしょうか?」ということだと思います。

「マイクロサービスは小さければ小さいほど良い！」と言う人もいます。

このとき、運用保守が飛び出してくる可能性があります。マイクロサービスを分割しすぎると、プロジェクトの複雑性が高くなりすぎます。これらのサービスの運用保守に人的資源が消費されるだけでなく、マイクロサービスの分割も必要以上になります。小さいものはリソースも占有します。

マイクロサービスの設計をガイドする適切な理論や設計方法はありますか?

答えはDDDです。

DDD は、戦略設計と戦術設計の 2 つの部分を含む複雑な領域を扱う設計思想です。戦略的設計は、ビジネスドメインモデルの確立、ドメイン境界の分割、および限定されたコンテキスト (DDD の専門用語。以下で説明します) の確立を支援することです。

戦術的設計は技術的な観点から始まり、ドメインモデルの技術的な実現に焦点を当て、マイクロサービスコードアーキテクチャモデルの設計と実装を含むソフトウェア開発と実装を完了します。

DDD のアイデアはマイクロサービスの分割をどのように導くのでしょうか? 次の 3 つのステップに分けることができます。

最初のステップは、ビジネスシナリオをリストし、ドメインエンティティオブジェクトを見つけることです。

2 番目のステップでは、ドメインエンティティ間のビジネス関連に従って、関連するエンティティが結合されて集約が形成されます。これらは同じマイクロサービスに属します。

3 番目のステップは、ドメインモデルを形成するために、意味論的な境界に従って、境界付けられたコンテキスト内で複数の集約を定義することです。この境界層はマイクロサービスの境界です。

DDD分野への思い

複雑な領域の問題を研究する場合、DDD は自然科学の研究手法と同様に、特定のルールに従って事業領域を細分化します。

自然科学の研究において複雑な問題に遭遇した場合、通常は、問題を一定のルールに従って細分化し、細分化された問題のサブフィールドを 1 つずつ詳細に研究していきます。あらゆる分野における完全な知識体系が確立されています。

例: 桃の木を研究したいとします。器官の違いにより、栄養器官と生殖器官に分けられ、栄養器官はさらに葉、茎、根に細分され、生殖器官はさらに花、果実、種子に分けられます。

臓器はさらに組織に細分されます。組織をさらに細分するには、組織をセルに細分します。細胞は私たちが研究したい最小単位です。細胞間の細胞壁は細胞の境界を定義し、研究の最小境界も定義します。

子域

桃の木は、根、茎、葉、花、果実、種子の 6 つのサブフィールドに細分されます。サブドメインは重要度に応じて分割されており、コアドメイン、一般ドメイン、サポートドメインに分かれています。

製品や企業の核となる競争力を決めるサブドメインがコアドメインであり、パーソナライズされた訴求が少なく、一般ドメインは複数のサブドメインで同時に利用されており、機能が含まれていない製品と企業の中核的な競争力を決定するものであり、サポートドメインである機能の一般的なサブドメインも含まれません。

なお、中核領域は企業の発展戦略や事業の実態に応じて決定されるべきである。

たとえば、この桃の木の所有者が庭師である場合、彼は満開の桃の花と春でいっぱいの庭を心配しているため、花が中心的な領域になります。この桃の木の所有者が果樹農家であれば、桃の品質と収量が気になるため、果実が中心領域となります。

限界上下文

言語にはそのセマンティック環境があることはわかっていますが、異なるコンテキストにおける同じ概念やセマンティクスのあいまいさを避けるために、DDD は戦略的設計において「境界付きコンテキスト」という概念を提唱しています。セマンティクスが見つかります。

たとえば、次の図の 2 つのアカウントは、名前だけでは区別できず、それらが配置されている限定されたコンテキストを通じてのみそれらの違いを確認できます。

また、例えば電子商取引分野における商品は、販売段階では商品ですが、輸送段階では商品になります。同じことですが、ビジネス分野が異なるため、これらの用語には異なる意味と責任の境界が与えられます。

境界のあるコンテキストはマイクロサービスに分割でき、この境界により、この境界内で概念が明確になります。

実在物

まとめると、4つの形式があります。

まず、エンティティのビジネス形式です。戦略的設計では、ドメインモデル内のエンティティは、複数の属性、操作、または動作を担います。

2 番目に、エンティティのコード形式: コードモデルでは、エンティティの形式はエンティティクラスであり、エンティティの属性とメソッド、およびコアビジネスロジックが含まれます。

DDD は「コードとしての設計」を重視します。「インフルエンザ予防接種」のビジネスユースケースについては、チームがビジネスモデルについて議論する際に、「看護師が患者に標準用量のインフルエンザ予防接種を投与する」と述べています。

従来のコードは次のようになります。

public void shot() {
    
    
    patient.setShotType(ShotTypes.TYPE_FLU);
    patient.setDose(dose);
    patient.setNurse(nurse);
}

DDD 思考のコード表現は次のとおりです。

public void shot() {
    
    
    Vaccine vaccine = vaccines.standardAdultFluDose();
    nurse.administerFluVaccine(patient, vaccine);
}

明らかに、2 番目のタイプのコードの方がはるかに理解しやすいです。

第三に、エンティティの動作形式: エンティティは DO (ドメインオブジェクト) の形式で存在し、各エンティティオブジェクトは一意の ID を持ちます。エンティティオブジェクトは複数回変更できますが、変更されたデータは元のデータとまったく異なる場合があります。ただし、同じ ID を持つため、同じエンティティであることに変わりはありません。

4 番目に、エンティティのデータベース形式: ドメインモデルがデータモデルにマッピングされる場合、エンティティと永続オブジェクトはほとんどの場合 1 対 1 になります。

値オブジェクト

値オブジェクトは DDD ドメインモデルの基本オブジェクトであり、エンティティと同様に複数の属性を含み、エンティティとともに集合体を形成します。

値オブジェクトのビジネス形式。

本質的に、エンティティは、見て触れられる具体的なビジネスオブジェクトであり、ビジネス属性、ビジネス動作、ビジネスロジックを持ちます。値オブジェクトは単なるプロパティのコレクションです。

値オブジェクトのコード形式。

public class Person {
    
    
    private Integer id;
    private String name;
    private Address address;
}

private class Address {
    
    
    private String province;
    private String city;
    private String county;
}

上記のコードを見てみましょう。個人エンティティには、id、名前、その他の属性などの単一の属性値オブジェクトがいくつかあります。また、住所 address などの複数の属性値オブジェクトも含まれています。

値オブジェクトの操作形式。

エンティティのインスタンス化後の DO オブジェクトのビジネス属性とビジネス動作は非常に豊富ですが、値オブジェクトによってインスタンス化されるオブジェクトは比較的単純です。

値オブジェクトのデータベース形状。

ドメインモデリングでは、エンティティの数を減らしながら、オブジェクトのビジネス上の意味を維持しながら、一部のオブジェクトを値オブジェクトとして設計できます。データモデリングでは、値オブジェクトをエンティティに埋め込み、エンティティテーブルの数を減らし、データベース設計を簡素化できます。。

一部のシナリオでは、アドレスはエンティティによって参照されますが、エンティティはエンティティを記述する役割のみを引き受け、その値は全体としてのみ置き換えることができます。このとき、アドレスを値オブジェクトとして設計できます。配送先住所。ビジネスシーンによっては、住所が頻繁に変更され、独立したオブジェクトとして存在する場合もありますが、その際には行政部門における住所情報の保守など、一体として設計する必要があります。