ドメイン駆動設計について理解したこと

DDD 101

プロジェクトが大きくなればなるほど、保守が大変になります。

基本的に、ドメインとは知識の領域のことで、チェスのルールのような公的なものか、非営利組織のビジネスルールのような私的なものかのどちらかです。 たとえば、オンラインでチェスを教えるNPOは、チェス、オンライン プラットフォームによる教育、および、あなたが生徒として課金されないとしても、その財務について知っているでしょう。

ドメインのそれぞれのサブドメインは、DDDでは境界コンテキストとして知られており、それぞれが、構成ブロックとして知られているコードの専門ユニットで構築した世界の独自のモデルを持っています。 ここでは、エンティティと値オブジェクトに焦点を当てますが、両方ともオブジェクトとして参照できます。

エンティティは、ドメイン内で一意であることを意味するオブジェクトです。 これは、与えられたエンティティを識別するために1つ以上のプロパティを使用することによって達成される。 例えば、あるシステムで同じ名前を使用する2人のユーザーは、電子メールを繰り返すことができないため、常に異なる電子メールを持ちます。多くの場合、エンティティはIDによって区別され、時にはプロパティの組み合わせによって区別されます。 例えば、2つのポーン（チェスのトークン）を例にとると、同じゲームセットから来て、同じ色を持っている場合、それらは同じに見えますので、それらを交換しても問題ではありません。 DDD では、値オブジェクトは不変なので、それを使って推論するのがより簡単です。

Data integrity

A bounded context does not expose all of its objects to guarantee its data integrity. その代わりに、それ自身への一種のパブリック インターフェイスとしていくつかの集約ルートを公開します。

集約は、他のオブジェクトで構成されるエンティティに他なりません。 より正確に言うと、アグリゲートは、データを変更するときにユニットとして扱う関連オブジェクトのクラスタです。

実務上、アグリゲートはツリーと呼ばれるデータ構造の形を取ることになるでしょう。 そのため、すべての集約はルートを持ちます。

他のオブジェクトが参照できる集約の唯一のメンバーはそのルートであり、したがって、これは私たちが公開するものです。 これは、集約が制御できない方法で他のオブジェクトがデータを微調整することを防ぐため、このように行われます。

それらのルートが外部に直接公開されていない場合でも、境界付きコンテキストが多くの集約を使用するかもしれないことを明確にすることが重要です。

複数の境界付きコンテキストへの対処

しかし、物事はより複雑になることがありますね？ 各境界コンテキストは、同じオブジェクトのわずかに異なるモデルを取得し、異なるプロパティと動作を持ちます。 たとえば、ゲーム コンテキスト内のユーザーは、金融コンテキストでは無関係であり、したがって存在しないスコアを処理するプロパティを持つことがあります。 また、境界のあるコンテキストではエンティティとして表されるドメイン概念が、別のコンテキストではオブジェクト-値として表されたり、完全に省略されることもあり得ます。

たとえば、教育コンテキストでは、教師が ID によって学生に割り当てられるようにエンティティとして表される必要がありますが、金融コンテキストでは、従業員エンティティの位置プロパティの値として「教師」を参照することが好まれます。

サービスは、エンティティやオブジェクト値には自然に適合しないドメインの機能です。

リポジトリはストレージ ユニットへのブリッジであり、こんにちは、CRUDです！

ファクトリはドメイン オブジェクトを作成するためのメソッドであり、無効な値を持つことはありません。

イベントは、ドメインで起こった何かを表すオブジェクトで、その専門家はそれについて気にします。 イベント駆動型アプリケーションを作成するための素晴らしい機会です。

Evans がそう述べたことを覚えていませんが、境界付きコンテキストは、コードをマイクロサービスに分割し、各サービスがそれ自体のコンテキストになる良い機会です。 最初のステップは、各コンテキストを同じアプリの異なるモジュールに入れる「仮想」分割かもしれません。

A language to rule them all

DD を学ぶときに最初に学ぶことの 1 つは、システムがユビキタス言語によって記述されるべきであるということです。 つまり、ドメイン専門家が私たちと話すときに使うのと同じ動詞 (メソッドまたはサービス) と名詞 (オブジェクト) を使ってコードを書くべきです。

このようにコードを書くことは、開発者と専門家が話しているときのコミュニケーション ギャップを埋めるという利点がありますが、現実を過度に単純化しているので、私自身はこれをガイドラインとして使用していますが最終解決策ではありません。

私にとってはDDDで最も重要なことは「複雑な」部分にあるので、通常は読まれないので、最後に取っておきました。

最近知ったのですが、著者自身が本で紹介する順番は最適ではないと言っていて、ここで紹介したものが理想に近い😍と思います。 こちらを参考にポッドキャストで聞きました

。