ドメイン駆動開発の勉強記録

記事

読む

hr.icon

hr.icon

Q&A

a.icon

a.icon

a.icon

a.icon

a.icon

a.icon

a.icon

a.icon

memo.icon

利用者にとって「重要な関心事」がちゃんと反映されてるのが良いドメインモデル

関心ごとの抽出テクニックはいろいろあるらしい

ex）一覧オブジェクト、区分オブジェクト、HowよりWhat

オブジェクトの生成・永続化はコード全体が複雑になる恐れがある

なので、生成・永続化はドメインモデルから分離する

具体的に言うと、ドメインオブジェクトを集約としてグルーピング

コンテキスト間の関係は色々あるらしい

ドメインの中でも更に注力すべきものを「コアドメイン」と言うらしい

ドメインとは

システム化の対象である問題領域です。例えば、在庫管理業務や病院カルテ管理業務などです。

ドメインモデルとは

ドメインに存在する概念 (用語や仕組み) を抽象化 (モデリング) したオブジェクトの集まり

ドメインに必要なすべての振る舞いは、1つのドメインオブジェクトの責務、または、いくつかのドメインオブジェクトの相互作用として実現されます。

おそらく、相互作用として実現されるの部分は、アプリケーションサービスとして実装するのだろう

ドメインオブジェクト

ドメインモデルを実装ベースで構成するオブジェクト

モデリングとは

対象にとって必要な振る舞い・属性だけを抽出すること

ドメインモデリングだと...

ドメインにおいて対象のモノ・コトが責務を全うできる振る舞い・属性だけを抽出すること

ドメインとは

対象とする事業が取り扱う世界を表しています。この世界には独自のルールと文化が存在しています。良い開発を行うためには、この世界をチームメンバーが深く理解する必要があります。しかし、すべての仕組みを理解するにはあまりにも大きく複雑すぎるため、通常は「コアドメイン」「サブドメイン」という適切な大きさに分割します。

ユビキタス言語の意味が変わる境界で「境界づけられたコンテキスト」を分割して管理します。

DDDの「コンテキスト」は「企業や組織の文化」に近い意味を持ちます。

1つの「境界づけられたコンテキスト」は複数チームではなく、1つのチームだけで担当します。そのためドメインエキスパートは自分の裁量でユビキタス言語を定義し、シンプルなモデルを構築できます。

大きなドメインをモデル化しようとすればするほど、次第に単一の統一的なモデルを構築することが難しくなります。

DDD では「境界づけられたコンテキスト」内で一意に認識可能な「ユビキタス言語」と言います。

ユビキタス言語とはソフトウェア開発チーム全体で作り上げる共有言語

別の境界付けられたコンテキストとやり取りする際にドメイン モデルの整合性を維持するための複数のパターンについて説明しています。 マイクロサービスの主要な原則の 1 つは、明確に定義された API を通じてサービスがやり取りするということです。 このアプローチは、Evans 氏が Open Host Service および Published Language と呼ぶ 2 つのパターンに対応します。

ドメイン分析のあとに行う、システム設計における、ドメインオブジェクトなどの話は、すべてサブドメインの中の話です。 つまり広義のドメインが、『広告運用業務領域』ドメインで、狭義のドメインが、『レポート作成業務』などのサブドメインです。

ドメイン駆動設計の本来あるべき姿としては1つのモデルに対して1つの境界づけられたコンテキストが紐づけられるがベターと考えられていると思います。

なぜなら複数のモデルに1つの境界づけられたコンテキストを紐づけるとモデルに変更が入る際、影響範囲が他のモデルまで波及してしまう恐れがあるからです。

まぁオブジェクト指向的な考えですね。

所感.icon

サブドメインは、ドメイン領域をどう分けるか

「境界付けられたコンテキスト」は、どの粒度でドメインを解決（実装・構築）するかって話

境界付けられたコンテキスト間は、干渉し合わない。

境界づけられたコンテキストごとにチームが振られ、各々で独立して開発が進められるイメージ。

各サブドメインごとに独立したユビキタス言語がある。

サブドメインと境界づけられたコンテキストの妥当性評価には基準があるらしい

境界づけられたコンテキスト間での似たモデルのやり取りのパターンは複数示されているらしい。

https://scrapbox.io/files/6165870ee7ed4d001f0e1cd0.png