書籍情報

個人的に印象に残った個所とメモ(※更新途中)

⇒ユビキタス言語とは「ドメインエキスパートやソフトウェア開発者を含めたチーム全体で作り上げる共有言語」

組織として、ドメインに関する有用なモデルを獲得できる ⇒ ビジネス的に最も重要なところの作業に注力する。まず注目するのはコアドメイン。モデリングをやりすぎたりはしない。
事業について、より洗練された正確な定義ができて、さらに深く理解できる
ドメインエキスパートが、ソフトウェアの設計に貢献できる
よりよいユーザー体験を提供できる
モデルとモデルの間に、明確な境界を定められる
エンタープライズアーキテクチャが、より整理されたものとなる
アジャイルでイテレーティブなモデリングを、継続的に行える
戦略的な面でも戦術的な面でも、新しいツールを使える

　　　｜Eコマースシステム
　　　｜在庫システム
　　　｜外部の需要予測システム

　　　｜在庫サブドメイン

　　　例)銀行取引コンテキスト・ アカウント
　　　　 文学コンテキスト・・・ アカウント
　　　　⇒ 全く違う意味だが、名前は同じ。

ドメインよりもデータを気にする場合、データモデルがオブジェクトに反映され、「ドメインモデル」の
ほぼすべての概念が、一つのエンティティと大量のゲッター／セッター群になってしまう。
エンティティには一意な識別子があって、変化するという特性がある。　⇒　これが「値オブジェクト」と異なる点
【CRUDベースの手法との対比】

DDDの文脈において、モデル内のモジュールは、ドメインオブジェクト内のひとまとまりのクラス群をまとめる、
名前付きコンテナとして機能する。
その目的は、別のモジュールのクラス群との結合を少なくすること。

適切な名前を付けることも重要になる。
モジュールの名前は、ユビキタス言語の重要な一面である。

ドメインの概念についての最新の状態を、モジュールに込めるようにしよう。

モジュールの「べし」「べからず」

モジュールは、モデリングの概念にフィットするように設計すべし
モジュールの名前は、ユビキタス言語に従うべし
コンポーネントの型やモデル内で使っているパターンなどから、モジュール名を機械的に決めるべからず
モジュールは、疎結合になるよう設計すべし
対等なモジュールどうしの結合が必須になる場合は、循環依存にならないようにすべし
　(対等なモジュールとは、同じ「レベル」にある、つまり、同程度の重要性だったり、同じ方向を向いて作られていたりするモジュールを指す)
親子関係のモジュールの結合の場合は、ルールを多少緩和すべし（親モジュールは上位レベルにあるモジュール、子モジュールは下位レベルにあるモジュールを指す)
モジュールをモデルの静的な概念とせず、モジュールが取りまとめるオブジェクト群にあわせて変えるべし

コアドメイン（スクラム）における集約の使用

プログラムって、要は使えてナンボのもんでしょ Linus Torvalds