前から読みたかったDDD本を、読み始めたので雑にメモしていく。

ドメインとは、そのシステムが解決したい問題の領域のこと。

DDDにおいてのモデルとは、以下のようなもの

これはDDDがモデル駆動開発で進められることを意味している。設計時にモデルを書きそこからコードを書き始める。また逆に、コードを書き始めて気づいたことなどをモデル側にも反映させることでモデルとコードを一緒に成長させていく。

これは後ほど出てくるユビキタス言語について。チームメンバ同士がコミュニケーションする際には、モデルや実際にコード上で表現されている言葉を用いる（逆にコミュニケーションに用いられる言葉をコードに落とし込む）

モデルはドメインの知識をそのまま反映したものであるべき。モデルと実装が紐付いていれば、コードから得た知見をモデルに反映できる。そうして、どんどん知識は噛み砕かれてよりドメインを明確に表すものに蒸留されていく。

これらの設計を進めていくためには、ドメインの知識を噛み砕く必要がある

第1章知識を噛み砕く

ドメインエキスパートの頭の中にあったり、過去のシステムなどからドメインに関する知識を得ることが重要で、繰り返し継続的にドメインに関する知識を学習する必要がある。得た知識の中から重要な概念を抽出し、それをそのままコードに落とし込む。

オブジェクト指向でよく言われる、名詞を抽出するという手法の他に、ビジネスルールなども概念として抽出する。

ビジネスルールなどはよくif文の中などに現れる。例えばATMでお金を引き出せる時間かどうかのロジックについて考えると、以下のように書かれることがある。（適当な疑似コード）

Time now = Time::Now();
Time am9 = Time(9,0,0);
Time pm10 = Time(22,0,0):

if (am9 < time && time < pm10)
{
    // 引き落とし処理
}

このようにしてしまうと、処理の中に重要な業務ルール（引き落とし可能時間）が隠れてしまう。そこでPolicyクラスなどを作成すると良いとされている。

if (businessHourPolicy.isAllowed(Time::Now()))
{
    // 引き落とし処理
}

ただしこのような手の込んだ設計はどこにでも適用することは推奨されていない。ドメインの中でも特に重要となる知識に対して行うことが重要。

このようにして書かれたコードはドメインエキスパート（非エンジニア）にもコードを見せることができ、プログラマの手助けがあれば理解することができる（はず）。

また、コードを書いたことによる気づきなどをモデルにフィードバックさせ、知識を深めていく。

アプリケーションが解決しようとしている問題の核心を表すうまいモデルのこと。深いモデルを見つけるために、開発を続け、ドメインの知識について継続的に学習・嚙み砕きを行うことが重要とされる。

雑なまとめ