Open9
DDDに出てくる単語とか概念メモ
miyatakaドメイン
システムが対象とする事業領域
miyataka戦略的モデリング
- ドメイン全体を個別のコンテキストに区切る．
- それぞれのコンテキストでのユビキタス言語を定義する．
- それぞれのコンテキストの関連性を図示したコンテキストマップも併せて作られる．
- コンテキスト同士の上下関係，並列関係などが図示される．
- 上下というのは，例えば，認証コンテキストは，独立して存在し，他のコンテキストの上流として存在しうる，というようなケース．
別にすべてのコードがどこかのコンテキストに含まれなければならない，ということはない．
戦術的モデリング
境界づけられたコンテキストの内側でのモデリングのこと．以下のような概念を利用しつつ整理する．
- エンティティ
- バリューオブジェクト（値オブジェクト）
- 集約
- リポジトリ
- サービス
- ドメインイベント
- モジュール
軽量DDD
上記のうち，戦術的モデリングのみを実践しようとすることを軽量DDDと呼び，DDDを重視する人からはアンチパターンとみなされることもある．文脈によるが蔑称のように使われることも．
miyatakaドメインエキスパート
当該事業領域のエキスパート．ベテラン．
ユビキタス言語
ドメインエキスパートとシステム開発者を含むチームが作り上げる共有言語のこと．
システム内部での言葉の使われ方と，ドメインエキスパートが実際に使う言葉を合わせるために，認識合わせ済みの言葉たち．用語集の形式をとったりもする．
単一の境界づけられたコンテキストのなかで用いられる．
換言すれば，特定のコンテキストでの主要な概念の一覧とその定義のあつまり．
miyataka境界づけられたコンテキスト（bounded context）
- ドメイン（事業領域）内部の明示的な境界の内部．コンテキストやサブドメインと言ったりする．
- コンテキストになりうるものとして以下のようなものがある．
- e.g. 保険，経理，銀行振替
miyatakaヘキサゴナルアーキテクチャ
- ポートとアダプターアーキテクチャと呼ばれたりする．
- ドメインモデルが中心にあり，インフラストラクチャは詳細である，とした考え方
- 綺麗な内側，内側とは切り離された外側，みたいなざっくりとした認識．
- 外部とのやりとりは，ポートもしくはアダプターという変換層を通してやりとりし，直接コードを利用することはない．
参考リンク
miyatakaエンティティ
- 一意な識別子を持っている（id, ***_id, uuid, guid, glidなど．ユーザーが指定するケースもある）
- カスタムした識別子を利用する場合，専用のバリューオブジェクトを作るのがよい．
- 識別子はエンティティが生きている間，変更してはならない．
- 同じプロパティ，フィールドをもっていても，区別すべきときがあるとき，それはエンティティになる．
- e.g. 同姓同名のユーザーは別モノとして扱う必要があるので，エンティティ．
- エンティティはリソースとイベントに分類できる
- 以前はマスタとトランザクションという区分けがされていたが，定義が曖昧になるので，今はこちらの区分けを使うのがベター
- 仕様を文章で記述したときに，名詞で表すのが「リソース」，動詞で表すのが「イベント」と捉えることができる
- 別の区分として，データとして「〜日時」を持つものがイベント，という見分け方もある
- 発送担当者が受注リストをもとに，商品の在庫を確認し、在庫があれば，商品を発送する
- ref. https://syobochim.hatenablog.com/entry/2016/09/04/140152
- リソースに「更新日時」を持たせたくなったら，イベントを抽出できていないことが原因であることが多い
- e.g. ユーザーエンティティに更新日時と退会フラグ（アクティブフラグ）があるなら，退会イベントが見落とされている可能性がある．
miyatakaバリューオブジェクト
- 識別子ではなく，値によって，同一性が比較されるモノ
- immutableである
- invalidな状態のバリューオブジェクトは存在してはならない
- できる限り，エンティティではなくバリューオブジェクトを利用すべき
- e.g. amount（量）というプロパティがあったとき，業務的な上限があるはず（たとえばECシステムを考えたとき，100冊以上は配送に影響がでるのでオンラインからは受け付けない，というような）．0以下のとき，業務的にはバリューオブジェクト自体が存在しないはず，などの制約があるはずなので，実際にintなど，primitiveなtypeを使うべき箇所はほとんどない．
miyatakaドメインモデル貧血症
ゲッターとセッターだらけ，かつドメインのロジックが表現されてない状態になっているモデルのこと．
参考
マーチン・ファウラー命名のドメインモデル貧血症は、ドメイン層っぽいデータをもつクラスを作りながらも、フィールドのGetter/Setterだけをつものを指す。そうしちゃうとドメインオブジェクトに業務知識が実装されず、それを使う側に任されることになる。
Always-Valid Domain Model
要はドメインオブジェクトは、Validな状態でしか生成・存在できないようにしようというもの
参考
miyatakaそもそもドメイン駆動開発が目指すもの
- ドメインエキスパートと開発者が見ているモノを一致させ，コード（ソフトウェア）の動きに一致させる．
- 業務知識がコードに詰め込まれた状態
- コード自体が業務知識を体現した状態
- 設計がコードであり，コードが設計でもある状態