第1章　知識を噛み砕く2024/09/03~

• ドメインモデルは、ドメイン知識を厳密に選び抜いて抽象化したもの。
• ドメインモデルを作成するには、エンジニアが中心となりドメインエキスパートや既存ユーザーから知識を引き出して膨大なコミュニケーションを行う必要がある。
• ソフトウェアの価値を最大化するために、DDDという考えが生まれた。
• プログラマーとドメインエキスパートがインタラクティブに対話することで、ドメインに対する知識やユビキタス言語を構築でき、ビジネスロジックをより忠実にプログラムに落とし込むことができる。

• ドメインのモデルの定義がソフトの価値を決定するほど重要で、ドメインに詳しくない段階で作成したドメインモデルは、ドメインエキスパートと対話を深め学ぶと大きく変わる変わることが往々にして有る。

第2章　コミュニケーションと言語の使い方 2024/09/05~

ユビキタス言語

• ドメインエキスパートと技術者の間に通訳が入ると翻訳にコストがかかるし、翻訳の段階で概念を抽象化した平均的な意味になるので、繊細にかつ的確に意味を捉えることができない。
• プロジェクトにおいて強固な共通言語を作成する必要がある。(ユビキタス言語)
• ユビキタス言語はドメインモデルと強い結び付きがある。
• ユビキタス言語を変更する際はそれに合わせて、ドメインモデル、クラス図、クラス名、関数名を変更しないといけない。
• ドメインエキスパートは、ドメインについての理解を伝えるのに使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになる曖昧さや不整合に目を光らせるべきである。

• 作成したユビキタス言語は、議論などで和語として使用しなといけない。実際に声に出して話すことが大事。人間は、話し言葉の複雑さに対してやや特化しているらしい。
• ユビキタス言語を使用して議論することは、モデリングをより良いものにできる。声に出して話すことで、気づくことができる不全さなどが有るので。
• そもそもビジネスのドメインに何らかの問題があり、ドメインエキスパートがうまく説明できないケースがある。ユビキタス言語はドメインエキスパート同士の議論でも有効で、モデルが自分たちの要件を満たすのに不十分だったり、誤っていると思われる領域を素早く発見することができる。

ドキュメントと図

• 議論の際はUML図を使うと良い。ホワイトボードなどに問題の中心となるオブジェクトをいくつか書くことで、議論に確固とした基盤が耐えられ、全員でオブジェクトの関係性について同じ見方を共有できる。
• 注意点として、PML図はオブジェクトの振る舞いや制約など、あまり細かいことを表現するのには向いていない。なので、図は主にコミュニケーションと説明の手段として、ブレインストーミングを容易にする為に夜いるべきである。

書かれたドキュメント

• ドキュメントは、コードの更新やプロジェクトで容易られる言語の更新にから置いていかれてしまいがちで、実際に役に立つドキュメントを書くのは難しい。
• プログラミングコードもアプリの仕様を説明するものだと考えるべきで、すでにコードが上手く行っていることを、ドキュメントにする必要はない。

説明のためのモデル

• 実装、設計、そしてチーム内のコミュニケーションの根底にあるモデルは１つだけであるべき。
• ただ、そのモデルは機能を満たすために必要最小限な形にまとめられてる。
• なので、その場その場の説明のために、よりわかりやすいモデル(図)を使うのは良いことだよ。

第3章 モデルと実装を結びつける 2024/09/10~

• オブジェクト指向データベースというのが有るらしい。オブジェクトをそのまま永続化できる。

実践的モデラ(HANDS ON MODELERS)

• モデリングとプログラミングを分離するとうまくいかない。
• モデラ(モデリングを行う人)と実装者が分離すると、実装の段階でモデルが軽視される場合や、実装的課題などが発生することでモデルからずれた成果物が出来てしまう。
• これ避けるために、モデルに貢献する技術者はだれでも、一定時間をコードに触れることに費やさないといけず、コードの実装に貢献する技術者は、コードからモデルの知識を深め、モデルに関する議論にいずれかの段階で参加しないといけない。

第4章 ドメインを隔離する 2024/09/14~